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Cross-Reference To Related Application 

10 The present invention is related to the subject matter of the following provisional 

United States Patent Application: "Adaptive Communication and Communication 
Server,'* naming inventors Henry Jay and Anil Annadata, filed February 6, 2001, Attorney 
Docket No. 5306.P012Z. Applicants hereby claim the benefit under 35 U.S.C. § 1 19(e) of 
the foregoing-referenced provisional application. The foregoing-referenced provisional 

15 patent application is hereby incorporated by reference herein in its entirety. 

Background 

In today's emerging technological and information world, companies are 
interacting with their customers, potential customers and other contacts through a wide 

20 variety of different communication channels. Such communication channels include face- 
to-face, telephone, fax, email, voicemails, wireless communication, Internet information 
inquiries via call me now and call me later, Internet collaborative sessions, paging and 
short messaging services. With all these communication channels, companies are faced 
with managing each customer interaction while meeting service levels and maximizing 

25 customer satisfaction. In addition, companies are faced with optimally staffing and 

training their workforce to deal with customers through these communication channels 
whether through their customer support center(s), telebusiness organizations, or their 
sales, marketing, and service professionals. 

Currently, many companies have dedicated email inboxes, fax inboxes, and 
30 voicemail boxes defined for specific business areas as well as automated call distributors. 
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Employees called agents are assigned to poll and manage the support requests from 
customers for each communication channel. Combined with the traditional call queues 
for inbound telephone calls, each agent is tasked with managing his or her work using all 
these communication channels while not having any visibility to the queue status and 
priorities of each customer support request and/or communication channel. 

Thus, it is desirable to provide a system that includes a universal queue strategy 
capable of assigning, routing, and queuing work items from multiple channels of 
communications to an agent having the appropriate skills to respond to the request. The 
system should enable the agent to view and manage his or her work items for all 
communication channels. Such a system reduces the response times and increases 
customer satisfaction, while balancing priorities amongst work items in multiple 
communication channels. 

Summary 

In one embodiment, a method for inter-module communication is disclosed. The 
method includes defining a command definition, wherein the command definition 
comprises commands for interfacing with a multi-channel, multi-media, communication 
queuing system. 

In one aspect, this embodiment includes driver object commands for requesting 
media type lists and command event lists, creating driver objects, requesting service, and 
releasing driver objects. 

In another aspect, this embodiment includes service object commands for 
releasing service objects, notifying when handling of an event is complete, invoking 
commands, releasing work items, suspending work items, resuming work items, handling 
queued events, and canceling queued events. 

In another aspect, this embodiment includes client object commands for starting a 
work item, releasing work items, saving work item contexts, restoring work item contexts, 
serializing work items, freeing work item storage, beginning batch processing, and ending 
batch processing. 
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In another embodiment, a inter-module communication definition is disclosed. 
The definition includes a command definition, wherein the command definition comprises 
commands for interfacing with a multi-channel, multi-media, communication queuing 
system. 

5 In one aspect of this embodiment, the command definition includes driver object 

commands to request media type lists and command event lists, create drivers, request 
service, and release drivers. 

In another aspect of this embodiment, the command definition includes service 
object commands to release service objects, notify when handling of an event is complete, 
10 invoke commands, release work items, suspend work items, resume work items, handle 
queued events, and cancel queued events. 

In another aspect of this embodiment, the command definition includes client 
object commands to start a work item, release work items, save work item contexts, 
restore work item contexts, serialize work items, free work item storage, begin batch 
15 processing, and end batch processing. 

The foregoing is a summary and thus contains, by necessity, simplifications, 
generalizations and omissions of detail; consequently, those skilled in the art will 
appreciate that the summary is illustrative only and is not intended to be in any way 
limiting. As will also be apparent to one of skill in the art, the operations disclosed herein 
20 may be implemented in a number of ways, and such changes and modifications may be 
made without departing from this invention and its broader aspects. Other aspects, 
inventive features, and advantages of the present invention, as defined solely by the 
claims, will become apparent in the non-limiting detailed description set forth below. 

Brief Description of the Drawings 

25 The present invention may be better understood, and its numerous objects, 

features, and advantages made apparent to those skilled in the art by referencing the 
accompanying drawings. 

Figs, t A through ID are a diagram of one embodiment of a system for enabling 
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and scheduling agents to respond to customer support requests and/or information 
requests via multiple communication channels of different media types. 

Fig. IE is a diagram of another embodiment of a system for enabling and 
scheduling agents to respond to customer support requests and/or information requests via 
5 multiple communication channels of different media types. 

Fig. IF is a diagram of components included in an implementation of a 
communication application programming interface. 

Fig. 1G is a diagram of components included in another implementation of a 
communication application programming interface. 

10 Fig. 1H is a diagram of components included in another implementation of a 

communication application programming interface. 

Fig. II is a diagram of components included in another implementation of a 
communication application programming interface. 

Fig. 1 J is a diagram of components included in another implementation of a 
15 communication application programming interface. 

Fig. IK is a diagram of components included in another implementation of a 
communication application programming interface. 

Fig. 2 shows an example of a database scheme for the system of Figs. 1 A through 

ID. 

20 Figs. 2a through 2cc show examples of tables corresponding to table names in Fig. 

2. 

Fig. 3 shows one embodiment of a universal queuing system in accordance with 
the present invention. 

Figs. 4a through 4p show examples of tables in a universal queuing database in 
25 accordance with the present invention. 
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Fig. 5 is a block diagram illustrating a network environment in which a system for 
enabling and scheduling agents according to embodiments of the present invention may 
be practiced. 

Fig. 6 is a block diagram illustrating a computer system suitable for implementing 
5 embodiments of the present invention. 

Fig. 7 is a block diagram illustrating the interconnection of the computer system of 
Fig. 6 to client and host systems. 

The use of the same reference symbols in different drawings indicates similar or 
identical items. 

10 Detailed Description 

Figs. 1 A through ID are a diagram of one embodiment of a client/server system 
100 for enabling agents to respond to customer support requests and/or information 
requests via multiple communication channels of different media types. These media 
types include, but are not limited to, telephone, email, fax, web collaboration, Internet call 
15 me now and call me later, web chat, wireless access protocol, paging, and short messaging 
services. The term customer is used herein to include individuals and contact persons at 
businesses that are customers of the company, potential customers and other persons with 
whom a customer support agent communicates. 

Fig. 1 A shows that four customers have submitted customer support requests to 
20 the client/server system 100 and one agent is responding to customer support requests. 
The four customers submitted the customer support requests via four communication 
channels 130, such as communication channels 130A, 130B, 130C, and 130D. In one 
embodiment, at least two of the four communication channels support different media 
types. 

25 In accordance with the present invention, client/server system 100 includes a 

universal queuing (UQ) system 102 capable of assigning, routing, and queuing work items 
from multiple channels of communication to an agent having the appropriate skills to 
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respond to a customer support request. The term work item refers to a request from a 
customer that requires a response from an agent assigned by client/server system 100, 
such as responding to a customer support request in the form of a telephone call, email, 
fax or other communication of a different media type. A work item can be initiated when 
5 an event such as an incoming customer support request arrives or by an agent using a user 
interface to client/server system 100. 

Client/server system 100 also includes a communication server 109 that enables 
agents to use communication channels of different media types to communicate with 
customers. Communication server 109 handles events such as the arrival of incoming 
10 customer support requests from a channel driver 120 such as one of channel drivers 120A, 
120B, and 120C. Each channel driver 120 communicates with a communication channel 
130 such as one of communication channels 130A, 130B, 130C and 130D. 

Interaction between UQ system 102 and communication server 109 occurs when, 
for example, communication server 109 receives and routes an incoming customer request 
15 as a work item to UQ system 102 for assignment to an agent. UQ system 102 assigns an 
agent to the work item and sends the work item back to communication server 109 for 
communication to the assigned agent. 

Web browser client 104A includes a web browser program such as Microsoft's 
Internet Explorer running on a client computer system (not shown). The web browser 
20 client 104A communicates with a web server 188. Application server 126 in client/server 
system 100 performs functions for and sends information to web browser client 104A via 
web server 188, which provides web pages for web browser client 104A to display. Web 
server 188 can download program instructions, such as Java applet 1 16, to the web 
browser client 104A to provide additional functionality, such as a user interface. 

25 Web browser client 104A is shown including a toolbar 105. One of skill in the art 

will recognize that other user interfaces providing the functionality of toolbar 105 can be 
implemented using a variety of different display formats to interface with multiple 
communication channels of different media types within the scope of the invention. 
Toolbar 105 is presented as part of a user interface. 
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In one embodiment, application server 126 of client/server system 100 includes 
object manager 107, session mode communication server 110, request mode 
communication server 140, inbound communication receiver 170, UQ system 102, web 
server 188, web server 146, Enterprise Application Interface (EAI) object manager 190, , 
and workflow process 144. In one embodiment, communication between components in 
application server 126 is enabled using a suitable inter-process communication protocol 
in conjunction with transfer control protocol/Internet protocol (TCP/DP) as known in the 
art. 

UQ business service 106 allows communication server 109 to request information 
from UQ system 102, which returns the information via web server 146, and EAI object 
manager 190. In one embodiment, both session mode communication server 110 and 
inbound communication receiver 170 can communicate with UQ system 102. Other 
embodiments can communicate with a third party queuing system for maintaining work 
item queues and assigning agents to work items. 

Communication server 109 includes session mode communication server 110. 
Communication server 109 may optionally include one or both of request mode 
communication server 140 and inbound communication receiver 170. It is important to 
note that the functionality provided by servers 1 10, 140, and 170 can be implemented on 
one server computer system or distributed across two or more server computer systems. 
Communication server 109 handles all communication between agents and customers via 
communication channels 130 of one or more media types. Communication server 109 is 
not media-specific and has no knowledge of communication channels or media. 

To communicate with multiple communication channels of different media types, 
communication server 109 is designed to communicate with a channel driver 120 such as 
one of channel drivers 120A, 120B, and 120C. A channel driver 120 is written according 
to Communication Application Program Interface (API) 125. Communication API 125 
provides an interface for third party vendors of communication devices and software (e.g., 
middleware vendors for communication devices) to provide a channel driver 120 so that 
their products are compatible with application server 126. By implementing a channel 
driver 120, vendors can take advantage of the customer support center management 
features and multi-media communication channel capabilities of application server 126. 
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Communication API 125 is designed to provide flexibility to third party vendors 
for integrating their products. In the implementation of a channel driver, a vendor defines 
the commands the vendor's communication channel 130 understands so that 
communication server 109 can issue commands for the communication channel 130 to 
5 perform. Normally these commands are issued when session mode communication server 
1 10 is presenting a user interface to the agent, although inbound communication receiver 
170 also can send commands in some circumstances. 

In addition, the vendor defines the events that the vendor's communication 
channel 130 provides regarding activity of a specific communication channel 130. 
10 Finally, the vendor provides a channel driver 120 implementation, such as a dynamic link 
library (.DLL file), for performing each command and generating and providing each 
event. The channel driver 120 implementation is required by communication API 125 to 
include code to instantiate a driver object and at least one service object. 

By requiring the vendor to provide facilities for the communication server 109 to 
15 issue commands to and to receive information from the vendor's communication channel 
130, communications API 125 enables communications server 109 to operate 
independently of the command channel 130 media type and specific protocols to 
communicate with the vendor's communication device or software. 

Referring to Fig. 2, an example of a database schema 200 that can be used by 
20 client/server system 100 (Fig. 1 A) for storing and communicating channel driver 

information, agent limitations on media access, commands and events, inbound task 
management, agent preferences, agent status, media status, communication channel 
configurations, multiple queue support, and agent management is shown. Database 
schema 200 includes data structures for configuration base 202, command and event 204, 
25 system base 206, response group 208, and email profile access control 210. 

Figs. 2a through 2cc show examples of tables corresponding to table names in Fig. 
2. Note that Fig. 2 does not indicate all of the relationships between the tables for 
simplicity, and that many instances of a table may exist for a particular configuration, 
depending on the number and types of communication channels authorized. Additionally, 
30 one skilled in the art will realize that this collection of tables, the parameters included in 
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each table, and the storage space allowed for the parameters, is one example of how the 
database schema may be configured, and that other suitable arrangements can be used in 
accordance with the present invention. 

The tables in Figs. 2a, 2b, 2c, and 2d are part of system base 206 and store channel 
5 driver information and channel driver parameters. The tables of Figs. 2a and 2b store the 
general information for a channel driver, such as channel drivers 120A, 120B, and 120C, 
and can be used by any customer support center configuration. The typical data stored in 
these tables are the file name of the channel driver DLL, the media type of the associated 
communication channel 130 (e.g. email, fax, etc.), a media string which is used by 
10 communication server 109 at run time to invoke a media service for the channel driver, 
the complete list of channel driver parameters, and the default value for each channel 
driver parameter. The parameters INB OUND_FLG and OUTBOUNDJFLG of table 
CNCTR (Fig. 2a) indicate whether the channel driver 120 supports inbound and/or 
outbound communications. 

15 Customer support centers can establish configurations that define the groups of 

agents that have similar requirements to communicate, therefore requiring access to the 
same communication channel 130. For example, salespersons within a company may 
need the ability to communicate via wireless access protocol, whereas telephone operators 
may not. A configuration can be established for each group within the company. A 

20 channel driver profile allows more than one customer support center configuration to 

share a single channel driver 120, with each additional channel driver profile overriding 
the values of some channel driver parameters such as the location of the channel driver 
DLL. For example, due to the network architecture of the company, salespersons for the 
company in Phoenix may use a different channel driver 120 than salespersons in Palo 

25 Alto. A channel driver profile will enable the Phoenix and Palo Alto salespersons to use 
the same channel driver but point to different DLLs. The term channel driver 120 is used 
herein to include at least one channel driver profile providing default values for the 
channel driver parameters. 

The tables in Figs. 2c and 2d store the channel driver profile for a particular 
30 customer support center configuration and the channel driver profile is not shared or used 
by other customer support center configurations. Typically, an administrator uses the 
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table CNCTR_PARM to override a default value for a channel driver parameter for the 
particular customer support center configuration. Referring to Fig. 2a, the string stored in 
the variable CNCTR_MEDIA_STR is based on a list of names of communication media 
supported by the channel driver 120. An administrator enters the name of the media in 
5 the CNCTR_MEDIA_STR field in character string format. The string stored in this field 
is used to determine the channel driver 120 to issue a command or from which an event 
originated. If one channel driver 120 supports multiple types of communication media, 
the administrator creates one record for each media type. The following examples show 
the parameters in the CNCTR table for telephone, email, and web chat media: 



Implementation",, "N"}, 

{"XYZ Email Driver", "Email", "xyz.dll", "Y", "Y", "XYZ Email 
Implementation",, "N"}, 

{"XYZ Web Chat Driver", "Web Chat", "xyz.dll", "Y'\ "Y", "XYZ Web-Chat 
15 Implementation",, "N"} 

Note that when a work item is submitted to UQ system 102 (Fig. 1 A) for agent 
assignment, the CNCTR„MEDIA_STR is also passed with the work item to help UQ 
system 102 to identify an agent with skills in using that media type. 



2. For the configuration ID, search the CFG_PROF table (Fig. 2o) for the list of 
channel driver profiles associated with the configuration. 



channel driver parameters from CNCTR, CNCTR_PARM, PROF, and PROF_PARM 
tables (Figs. 2a-2d, respectively). 

An example of an algorithm for loading a list of channel drivers 120 upon the 
agent logging in to client/server system 100 is as follows: 



10 



{"XYZ Phone Driver", 'Telephone", "xyz.dll", "Y", "Y", "XYZ Phone 




25 



3. For each of channel drivers 120, load the channel driver information and 



30 



1. For each of channel drivers 120, 



a. If the DLL has not loaded, load the DLL 
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b. Pass the channel driver parameters and ask the channel driver for the 

handle of a driver object. 

c. Request the handle of a service object by passing the media type of the 

channel driver identified in CFG_PROF (Fig. 2o) as being 
5 associated with the agent. 

2. End loop 

By default, an agent is authorized to access all channel drivers 120 associated with 
the configuration to which the agent belongs. For example, if the agent belongs to 
"Customer support center 1," all channel driver profiles configured in "Customer support 
10 center 1" are accessible for all agents in "Customer support center 1" by default. The 
administrator can further limit the agent's access to channel drivers 120 using table 
AGENTJUM (Fig. 2m) that lists the channel driver profiles the agent cannot access. 

Agent preferences are stored in table AGENT_PREF (Fig. 2e) in a centralized 
database so that an agent's settings are available independently of the type of client or 
15 communication channel being used. A user interface for modifying the settings is also 
supplied in an embodiment of the present invention. 

Embodiments of the present invention support multiple communication media 
channels and agent assignment with UQ system 102 (Fig. 1 A). Table AGENT_STAT 
(Fig. 2f) stores the current working status of a particular agent for all types of media that 
20 the agent is authorized to use. From this table, the administrator can see a list of media 
types that agent is currently authorized to access and the status of each media type. 

When the "NOT_READY_FLG" parameter in table AGENT_STAT (Fig. 2f) 
indicates that an agent is not ready to take work items, UQ system 102 (Fig. 1 A) will not 
assign any work items to the agent. The "BUSY_FLG" parameter indicates that the agent 
25 is busy. 

Table AGENT_STAT is updated mainly at run time. When the agent first logs on 
using the user interface, one record for each media type that the agent is authorized to 
access is created. For example, 

{"agent_emp___id'\ "Phone Control", "", "1234", ""}, 
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ragent_emp_id'\ "Email/Fax", "", "", "1234", ""}, 
{"agent_emp_id", "Web Chat", "", "", "1234", ""} 

The records are updated according the agent's working status. For example 
{"agent_emp_id", "Phone Control", "Y", "", "1234", "Y"} indicates that agent is 
5 not ready but is talking on the phone, 

{"agent_emp_id", "Email/Fax", "Y", "", "1234", ""} indicates that the agent is 
not ready to accept Email/Fax type of work, and 

{"agent_emp_id", "Web Chat", "N", "", "1234", "Y"} indicates that the agent 
is ready to accept web chat type work and he or she is currently working on a web chat 
10 session. 

Referring to table MEDIA„STAT (Fig. 2d), the parameter 
"MEDIA_OBJECT_STR" for phone is the agent's extension number. For email, it is the 
mailbox name or the sender's email address. For fax, it is the fax number. The form of 
the content of MEDIA_OB JECT_STR is defined in each of the channel drivers 120. 

15 "WORKING_SINCE_DT" is the time the agent starts to talk on the phone, or the 

time the agent starts to work on a work item such as an email or fax. 

"WORK_ITEM_STR" is the unique string to identify the work item and the value 
of the field is determined by communication server 109. The MEDIA_STAT table is 
updated at run time to reflect the agent's current work status. An example of an agent's 
20 data records at run time is as follows: 

{"agent_id", "Phone Control", "Ext. 5216", "6/25/2000 12:34:45", 
"phone_item_str", "1-1 S2-X7E" } , 

{"agent_id", "Email", "info@company.com", "6/25/2000 11:34:00", 
"email_item_str", "1 - 1 S2-X7D" } 

25 The above records show that the agent is currently talking on extension 5216 and 

is working on an email sent to info@company.com. 

Multiple extensions and multiple queues are supported in client/server system 100 
(Fig. 1 A) using tables TELESET, EXTENSION, and AGENT_QUE, Figs. 2h, 2i, and 2j, 
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respectively. The following terms are referenced in Figs. 2h, 2i, and 2j. The term 
automatic call distribution (ACD) extension refers to a type of extension that is used to 
log in to an ACD queue associated with an ACD switch such as ACD switch 130E . Once 
an extension logs in to the ACD queue, the ACD switch begins to dispatch customer calls 
5 to the extension. One ACD extension can log in to one or more ACD queues. 

The term standard extension refers to a type of telephone extension that is not 
allowed to log in to the ACD queue. Standard extensions are mainly used for dialing 
outbound calls or answering internal calls. The ACD switch does not dispatch customer 
calls to a standard extension. 

10 The term agent ID refers to an identifier used by client/server system 100 to 

identify the agent. In order for client/server system 100 to be aware of the agent's 
availability, each customer support center agent is assigned an agent ID. When the agent 
logs in to a communication channel having an ACD switch 130E, the agent ID is provided 
to the ACD switch 130E. Depending upon the configuration of the system, either the 

15 ACD switch 130E or UQ system 102 determines an available agent ID for the work item. 
Then either the ACD switch 130E dispatches the customer call to the ACD extension of 
the agent ID or, when UQ system 102 is used to assign agents, communication server 109 
uses one of channel drivers 120 to dispatch the customer call to the ACD extension of the 
agent ID. 

20 "Multiple DN" refers to multiple extensions configured for one telephone handset, 

and one or more extensions are ACD extensions. 

"Multiple queue" means that one ACD extension can log in to multiple queues. In 
general, since an ACD queue is a list of agent IDs, as long as the agent ED is acceptable 
for ACD queue, any ACD extension can be used to login to ACD queue. 

25 In one embodiment, a method for determining the list of extensions for an agent 

includes searching by the agent's ID in the AGENT table (Fig. 2j) to find the primary 
Teleset ID in the ACTIVE_TELESET_ID parameter, which identifies the primary 
handset used by the agent. The extension list is then determined from the DN_EXT 
parameter in the EXTENSION table (Fig. 2i). Once the list of extensions is found, all 
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extensions that the agent uses can login to all ACD queues defined in the AGENT_QUE 
tables (Fig. 21) for that particular agent. 

As described above, customer support centers can establish configurations that 
define the groups of agents that have similar requirements to communicate, therefore 
5 requiring access to the same communication channel 130. Configuration base 202 
includes tables about configurations. CFG table (Fig. 2n) contains information about 
configurations. Configuration data includes a configuration name and an INGRP_FLAG 
indicating whether this configuration is for inbound response groups used in inbound 
communication receiver 170. CFG„PROF table (Fig. 2o) is the configuration / channel 
10 driver profile relationship table showing which channel driver profiles belong to each 
configuration. Each configuration has a single channel driver profile. 

AGENT_CFG table (Fig. 2p) is the agent / configuration relationship table 
showing which agents belong to each configuration. 



CFG_PARM table (Fig. 2q) is the configuration parameter table. A name and a 
15 value are provided for each configuration parameter. An ACTTVE_FLG field is a flag 
indicating whether the value of the configuration parameter is active. 



The command and event data structure 204, includes information describing 
commands and events implemented by channel drivers 120. This information includes 
associating each command with a channel driver 120 and each event with a channel driver 
20 120. 

CMD table (Fig. 2r) includes commands for each channel driver 120. As 
described above, a vendor providing a channel driver 120 specifies the commands that it 
supports. A command is issued to channel driver 120 by communications server 109 to 
perform a command using communication channel 130. Every click on a button of 
25 toolbar 105 invokes a command, which is issued to channel driver 120. 

A command can have a group of associated commands which operate as 
subcommands. A group command includes other commands with a Subcommand 
keyword. 
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Following is an example of a single command for making a telephone call to a 
contact. 



[Command: MakeCalltoContact] Command definition 

CmdData = "MakeCalltoContact" Command parameter 

5 DeviceCommand = "MakeCall" Command parameter 

Description = "Make Call to Contact" Command param. 

Hidden = TRUE Command parameter 

[CmdData: MakeCalltoContact] Command data def. 

BusComp = "Contact" Command parameter 

10 RequiredField. 'Work Phone #' ="?*" Command parameter 

Param.PhoneNumber = "{Work Phone # : Lookup} 

Command 



Parameter 



15 Following is an example of a group command for making a telephone call to a 

contact: 

[Command: MakeCallGroup] 

Hidden = TRUE 

Subcommand = MakeCalltoPhone 

20 Subcommand = MakeCalltoSRContact 

Subcommand = MakeCalltoSROwner 

Subcommand = MakeCalltoEmployee Home 



The following example command can be either a single command or a 
25 subcommand 



[Command: MakeCalltoPhone] Command definition 

CmdData = "MakeCalltoPhone" Command parameter 

DeviceCommand = "MakeCall" Command parameter 

30 Description = "Make Call to { ©Phone}" Cmd param 

Hidden = TRUE Command parameter 

[CmdData: MakeCalltoPhone] Command data def. 

[CmdData: MakeCalltoPhone] Command data def. 

RequiredField/ Work Phone #' ="?*" 
35 Param.PhoneNumber = "{©Phone: 

PhoneTypeLookup } 

A command can have a command data section with a CmdData keyword to 
specify the data parameter in order to communicate with channel driver 120. 
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When a customer support center configuration includes multiple channel drivers 
120, it is then possible for communication server 109 to determine which commands and 
events are handled by each of channel drivers 120. This configuration can also help 
distinguish between channel drivers 120 from different vendors that use the same name 
for commands performing different functions. 

Following is an example of a command with a data section having a CmdData 
keyword 

[Command: MakeCalltoContact] 

CmdData = "MakeCalltoContact" 

DeviceCommand = "MakeCall" 

Description = "Make Call to Contact" 

Hidden = TRUE 

[CmdData: MakeCalltoContact] 

BusComp = "Contact" 
RequiredField.'Work Phone #' ="?*" 
Param.PhoneNumber = "{Work Phone # : Lookup} 

The event table contains events that are sent to communication server 109 from 
channel driver 120. Vendors specify the events that will be sent in channel driver 120. 
An event response determines how communication server 109 reacts upon receiving each 
media event. The process of handling an event includes the following: searching for the 
event handler for the event, querying a customer support center database to determine the 
appropriate event response, and logging the event. 

An example of an event, the event handler, event response, and event log for an 
InboundCall event are shown below: 



[EventHandlenOnlnboundCall] 
DeviceEvent = "EventRinging" 
Response = "OnlnsideCallReceived" 

Filter.Call = "?*** 
Order ="1" 



first stage, EventHandler definition 
media event definition 
EventResponse declaration 
EventHandler parameter 
EventHandler order 



[EventResponse:OnInboundCallReceived] second stage, EventResponse 

definition 

QueryBusObj = "Contact" EventResponse parameter 

QueryBusComp = "Contact" 

QuerySpec = "'Work Phone #'='{ ANI} ,M 
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Single View = "Service Contact Detail View" 

MultiView = "Contact List View" 

FindDialog = "Service Request" 
FindField.CSN = "Ask Caller" 

FindLog = "LoglncomingCallContactNotFound" EventLog declaration 

SingleLog = "LoglncomingCallContactFound" EventLog declaration 

Log = "LoglncomingCallContactNotFound" EventLog declaration 



[EventLog:LogIncomingCallContactFound] 



B EventLog definition 
B EventLog parameters 



Display = "TRUE" 

BusObj = "Action" 

BusComp = "Action" 



LogField.Type = "Call - Inbound" 
LogField.' Account Id' = "{Contact. 'Account Id' }" 
LogField.'Contact Id' = "{Contact. Id}" 
LogField.Description = "Inbound call" 
LogField.'Call Id' = "{ConnID}" 
AfterCall.'ACD Call Duration'= "{ ©CallDuration}" 

Each event handler corresponds to an event provided by channel driver 120 and it 
is sequenced among the event handlers for an event. Each event handler has an event 
response. An event response can be shared among event handlers. An event response can 
have multiple event logs, and an event log can be shared among event responses. 

When operating in session mode, communication server 109 is under the control 
of session mode communication server 110. Session mode communication server 110 
receives incoming events such as customer support requests and communicates 
interactively with the agent by controlling a user interface presented to the agent. 
Preferably the incoming customer support request is communicated to the agent at 
substantially the same time the customer support request is received by the 
communication channel 130, with brief intermissions only to allow for processing and 
transport time in transporting the customer support request. This ensures that the 
customer's waiting time is minimized, particularly for requests for live interaction with an 
agent. 

When an event such as arrival of an incoming telephone call occurs, the user 
interface notifies the agent using a notification function to change the user interface to 
capture the agent's attention. For example, a notification function can cause a button to 
blink to notify the agent of the phone call. A notification function can also display other 
information such as information about the caller before the agent picks up the phone. 
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When the agent uses toolbar 105 to accept a telephone call, put a call on hold, or release a 
call, the user interface sends a command to session mode communication server 1 10, 
which communicates with one of channel drivers 120 to issue the command to the 
communication channel controlling the telephone. 

5 Session mode communication server 110 also handles establishing and 

maintaining connections to one or more communication channels 130, such as 
communication channels 130A through 130D. Session mode communication server 1 10 
uses one of channel drivers 120, such as channel driver 120 A, to establish the connection. 
Having a connection to a communication channel enables the agent to receive an 

10 incoming work item, such as an email, intended specifically for that agent in real time. 

The connection can be to a middleware server, to a web server, directly to a media device, 
or to any other communication intermediary from which the customer can receive a 
communication. The connection can be established as a TCP/IP socket connection to a 
middleware server, as an OLE interface such as the IadviseSink interface, or as any other 

15 suitable inter-process communication scheme. Each of channel drivers 120 contains all 
information needed to establish the connection with communication channel 130 so that 
communication server 109 operates independently of communication channel 130. 

Fig. IB shows a detailed view of one embodiment of session mode 
communication server 1 10. Session mode communication server 1 10 maintains 
20 knowledge of clients 104 to which it is connected, here web browser client 104 A. When a 
communication from communication channel 130 such as ACD switch 130E is received, 
communication server 109 dispatches the request to the appropriate server component in 
client/server system 100 for execution. 

Session thread 122 represents a session during which an agent interacts with 
25 client/server system 100 using web browser client 104A. A customer uses a customer 

communication device, here a telephone, to access the communication channel. The agent 
also uses a communication device, such as a telephone headset, to access the 
communication channel. 

Session thread 122 listens for inputs from its web browser client 104A and 
30 dispatches notifications of events from ACD switch driver 120D to web browser client 
104A. Session thread 122 uses a communication channel manager such as 
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communication channel manager 124 to interact with ACD switch driver 120D. Each 
channel driver 120 provides an active connection such as active connection 133 between 
the client and the associated communication channel. Channel driver 120 can be 
implemented to establish a persistent connection for interactive communication between 
client 104 and communication channel 130E but providing a persistent connection is not 
required by communication API 125. 

The following examples describe processes that are followed by web browser 
client 104A during startup, initialization and operation. The processes for web browser 
client 104A are applicable to other types of clients, as will be explained in further detail 
below. 

When web browser client 104A begins execution: 

1. Web browser client 104A downloads program instructions for generating a user 
interface on the display for the web browser, such as toolbar 105, shown here as 
implemented using Java applet 1 16, from web server 188. Java applet 116 also 
establishes persistent HTTP connection 131 between Java applet 116 and web server 188 
so that web server 188 can continuously provide information to web browser client 104 A. 

2. Web browser client 104 A interfaces with session mode communication server 
1 10 via web engine session thread 166. Object manager 107 spawns web engine session 
thread 166 to interface with web browser client 104A using web engine plug-in 185 and 
web engine 115. Communication client service 160 provides all communication related 
to the user interface with web browser client 104A. 

3. Communication client service 160 requests the object manager 107 for 
communication service. Communication service 113, which provides all 
communications not related to the user interface, is provided. 

4. Communication service 113 loads configuration information such as 
commands, events, agent information and preferences, channel driver information and 
channel driver parameters. 

5. Communication service 1 13 registers an asynchronous event receiving function 
with object manager 107 to be invoked when an asynchronous event is subsequently 
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received. The asynchronous event receiving function is also referred to as a callback 
function. Receiving asynchronous events is described in further detail below. 

6. Communication service 113 request an active connection 135A between object 
manager 107 and web engine plug-in 185 and an active connection 135B between 
communication service 113 and session mode communication server 110. Persistent 
HTTP connection 131, and active connections 135A and 135B enable session mode 
communication server 110 to continually push user interface changes to toolbar 105 using 
Java applet 116. 

7. Session mode communication server 110 spawns a session thread such as 
session thread 122 in response to the connection request. 

8. Session thread 122 runs communication channel manager 124. 

9. Communication channel manager 124 loads ACD switch driver 120D and 
passes the channel driver parameters determined by communication service 113. 

10. ACD switch driver 120D establishes an active connection 133 to the ACD 
switch 130E. A vendor implementing channel driver 120 may choose to provide a 
persistent connection to the communication channel 130, as for telephone connections 
such as active connection 133. However, a persistent connection is not required by 
communication API 125. 

When the agent performs an activity using web browser client 104A that requires 
a command to be executed, such as clicking a button on toolbar 105: 

1. Communication client service 160 searches the command configuration data 
previously loaded for the command to invoke. It also collects the data associated with that 
command and then passes the command and data to communication service 113. 

2. Communication service 113 passes the command and data to communication 
channel manager 124. 

3. Communication channel manager 124 then determines which of channel 
drivers 120 performs the command requested by the client, and passes the command and 
data to the channel driver 120 such as ACD switch driver 120D for execution. 
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4. ACD switch driver 120D issues the command to the communication channel 
130. In this example, the ACD switch driver 120D issues the command to ACD switch 
130E. 

When a channel driver 120 such as ACD switch driver 120D needs to push an 
5 event (status data or an incoming event such as a customer call) to web browser client 
104A: 

1. ACD switch driver 120D receives the event and posts the event to 
communication channel manager 124. This requires asynchronous interruption at session 
thread 122 for event posting. 

10 2. Communication channel manager 124 pushes the event to communication 

service 113. 

3. Communication service 113 receives the event and executes the registered 
asynchronous event receiving function. 

4. The registered asynchronous event receiving function inserts the event sent 
15 from ACD switch driver 120D into an event queue stored inside object manager 107. 

5. A frame manager (not shown) running in session thread 122 picks up the event 
from the event queue and invokes the registered asynchronous event receiving function 
using communication client service 160. 

6. Communication client service 160 asks communication service 113 to process 
20 the event. 

7. After communication service 1 13 has processed the event, communication 
client service 160 continues to communicate with Java applet 116 to control the web 
browser for user interface changes. 

Fig. 1C shows components included in one embodiment of request mode 
. 25 communication server 140. Request mode communication server 140 handles the 

distribution of information via communication channels according to the request. An 
example of the operation of request mode communication server 140 is session mode 
communication server 110 sending a request to request mode communication server 140 
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to send a large number of emails on its behalf. This enables session mode communication 
server 1 10 to devote its resources to controlling the user interface, issuing commands, and 
handling events. 

A request mode server thread such as server thread 142 is spawned when request 
5 mode communication server 140 begins execution. Communication manager 152 is 
loaded to collect data for the request. Request mode communication server 140 
determines the appropriate channel driver to handle the request and directs a 
communication channel manager 156 to load email driver 120E. Communication channel 
manager 156 dispatches the request and data to email driver 120E, which sends the 
10 information to email communication channel 130F. In the embodiment shown in Fig. 1C, 
email driver 120E sends the emails via email server 132 to email client 134. 

As another example of the operation of request mode communication server 140, 
object manager 107 can send one or more work items from UQ system 102 to request 
mode communication server 140. Similar to the previous example, a request mode server 

15 thread is spawned and communication manager 152 is loaded to collect data for the 

request. Request mode communication server 140 determines the appropriate channel 
driver to handle the request and directs a communication channel manager 156 to load an 
appropriate driver, such as email driver 120E. Communication channel manager 156 
dispatches the request and data to the driver, which sends the information to a 

20 communication channel. 

Fig. ID shows an example of one implementation of inbound communication 
receiver 170. One embodiment of inbound communication receiver 170 is designed to 
serve inbound customer support requests with no connection to or knowledge of a client. 
This contrasts with session mode communication server 110, which communicates with a 

25 client to provide a user interface to at least one agent. In one implementation, inbound 
communication receiver 170 handles customer support requests that can be held in a 
queue for future processing, such as fax and email, whereas session mode communication 
server 1 10 handles high priority support requests that should be processed as quickly as 
possible, such as telephone calls, to improve customer response time. In another 

30 implementation, both inbound communication receiver 170 and session mode 
communication server 110 can handle high priority support requests. 
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Inbound communication receiver 170 uses channel drivers 120 such as email/fax 
channel driver 120F to "listen" for particular types of customer support requests from a 
common source. Email channel driver 120F handles all email messages directed to a 
particular email address and all faxes sent to a particular fax number. To avoid overlap 
5 among agents, inbound communication receiver 170 can be configured to work with UQ 
system 102 to assign an agent to the inbound customer support request (email 173 or fax 
175) and route the customer support request to a component associated with or 
representing the assigned agent, such as a client. 

Inbound communication receiver 170 is also configured during initialization to 
10 recognize events, such as receiving a customer support request, and to include 

corresponding channel driver information and background profiles to handle recognized 
events. Background profiles include one or more monitored media objects, such as a list 
of email addresses, fax numbers, and web-chat end points. For example, email 
communication channel 130G represents a background profile for info@company.com 
15 and fax communication channel 130H represents a background profile for fax number 1- 
800-123-4567. 

Inbound communication receiver 170 spawns a server thread such as server thread 
174 to handle inbound events, such as customer support requests. This contrasts to 
session mode communication server 110, which spawns a session thread such as session 
20 thread 122 for each client 104 being used by an agent. Communication channel manager 
177 then initializes a service such as fax service object 183A, email service object 183B, 
or phone service object 183C with the designated background profile. 

When the email/fax channel driver 120F receives an incoming customer support 
request, e.g. new fax 175, fax channel driver 120F posts the event to communication 

25 channel manager 177. This posting interrupts the idle state of server thread 174 and 

causes server thread 174 to invoke communication channel manager 177 to process the 
event. Communication channel manager 177 determines how to respond to the event 
based on an event response included in an event response table, such as EVTRESP (Fig. 
2y), and invokes the appropriate media service, such as fax service object 183 A. If the 

30 event response also specifies notifying UQ system 102 of the event, the event is then 
passed to UQ system 102 via UQ business service 106. A response to the event 
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notification is returned to inbound communication receiver 170 via UQ business service 
106. 

In alternative embodiments, client/server system 100 can support multiple types of 
clients 104 having hardware/software configurations that are different from web browser 
client 104A. Fig. IE shows an alternative embodiment of client/server system 100 that 
supports web browser client 104A, thin client 104B, and dedicated client 104C. 

Thin client 104B includes one or more client software modules that are installed 
and executed on the client computer system used by the agent. Thin client 104B provides 
minimal functionality, with the majority of the functions for thin client 104B are 
performed by application server 126. It is often desirable to use thin clients so that 
application programs can be updated once in a centralized location instead of multiple 
times for each thin client 104B. 

Thin client 104B provides more functionality on the client side than web browser 
client 104A, and can, for example, perform some functions of object manager 107. Thin 
client 104B also controls the user interface including toolbar 105. If changes are 
necessary to the functions performed on the client side, a new copy of thin client 104B 
must be installed on each individual agent's computer system. 

Dedicated client 104C includes software modules that perform a significant 
portion of the functions required to support an agent. Dedicated clients are sometimes 
referred to as "fat clients," in contrast to the "thin client" designation. If changes are 
necessary to the functionality provided by dedicated client 104C, a new copy of the 
dedicated client software modules usually must be installed on the client computer 
system. 

Dedicated client 104C provides even greater functionality than does thin client 
104B, including, for example, all functionality provided by object manager 107, web 
server 188, communication client service 160 (Fig. IB), and communication service 113. 
Because dedicated client 104C assumes all responsibility for the user interface and toolbar 
105, there is no communication between dedicated client 104c and communication server 
109, web server 188, web engine plug-in 185 and web engine 115 (Fig. IB). Dedicated 
client 104C does include web server 149 that is capable of interfacing with UQ system 
102, and object manager 151 to communicate with channel drivers 130. 
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It is important to note that other types of clients having hardware and software 
components that are different from clients 104A, 104B, and 104C can also be integrated 
with client/server system 100. 



Communication API 

5 Referring now to Figs. 1F-1J, communication API 125 is provided in one 

embodiment of the present invention for channel drivers 120 to communicate with 
communication server 109. Note that communication server 109 is used in the following 
discussion of communication API 125 to represent session mode communication server 
1 10, request mode communication receiver server 140, or inbound communication 
10 receiver 170. 

As shown in Fig. IF, one embodiment of communication API 125 includes three 
types of objects: driver objects 189, service objects 183, and client objects 183. Driver 
objects 189 and service objects 183 are instantiated at the channel driver 120, however 
client objects 179 are instantiated at communication server 109. Communication server 
15 109 interfaces with driver objects 189 and service objects 183, but only service objects 
183 communicate with client objects 179. 

Driver objects 189 maintain the instantiation of service objects 183. Any special 
steps for constructing and destructing service objects 183 can be implemented in driver 
objects 189. Multiple driver objects 189 can be included to manage different types of 
20 media. Also, a single driver object 189 can manage one type of service objects 183 or 

different types of service objects 183. For example, a single driver object 189 can manage 
phone, email and fax media. 

As an example of the operation of driver objects 189, when communication server 
109 is starting up, the channel driver 120 data link library (DLL) is loaded. 
25 Communication server 109 calls CreateISCSDriverInstance() in channel driver 120 to ask 
for the construction of a driver object 189. The channel driver 120 returns the driver 
handle back to communication server 109. The channel driver 120 determines how driver 
objects 189 are created. If driver objects 189 already exist, for example, the channel 
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driver 120 could simply pass the handle of an existing driver object 189 instead of 
creating a new one. 

In one embodiment, service objects 183 are created by driver objects 189 and 
provide functionality in the form of device commands to.interact with the associated 
media type. For example, making an outbound call, or sending an outbound email is 
implemented at service objects 183. A service object 183 is usually associated with a 
single type of media. For example, there can be service objects 183 for phone media and 
other service objects 183 for email media. Communication server 109 interfaces directly 
with service objects 1 83 to invoke a device command. 

After communication server 109 obtains the driver handle, communication server 
109 uses a RequestService() function to request a service object 183 for the specified 
media type. The driver returns the handle of the corresponding service object 183 to 
communication server 109. Communication server 109 then uses this handle in an 
InvokeCommandO function directly to request the corresponding service object 183 for 
executing a particular type of function. 

After communication server 109 obtains the handle to a service object 183, 
Communication server 109 will use the service handle directly to interact with the service 
object 183. Service objects 183 can inherit facilities from, and/or share resources with, 
driver objects 189. For example, driver objects 189 can maintain the physical TCP/IP 
connection to a middleware server and service objects 183 can share the connection with 
the driver objects 189. 

Client objects 179 are instantiated and implemented by communication server 109. 
The handles to client objects 179 are passed to service objects 183. Service objects 183 
can utilize the client handles and invoke the function to be executed at communication 
server 109. 

In one embodiment, every service object 183 has a corresponding client object 
179. Therefore, each client object 179 has knowledge of the media type that its 
corresponding service object 183 is using. Since service objects 183 can each be 
instantiated for different media from different driver DLLs, this one-to-one relationship 
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allows a client object 179 to know the driver object 189 and service object 183 that 
initiate the notification when client object 179 receives notification from service object 
183. 

Fig. 1G shows an example of an architecture for driver object 189 instantiated by 
5 channel driver 120. Driver object 189 creates three service objects 183A-1, 183A-2, and 
183A-3 of the same media type, such as email. Each service object 183A-1, 183A-2, and 
183A-3 has its own dedicated client object 179A-1, 179A-2, and 179A-3, respectively. 

Fig. 1H shows an alternative architecture for driver object 189 that creates three 
service objects 183 A, 183B, and 183C for different types of media. Each service object 

10 183A, 183B, and 183C has its own dedicated client object 179A, 179B, and 179C, 

respectively, for processing events with the corresponding media type. An example of 
this architecture is shown in Fig. ID for inbound communication receiver 170 that 
includes client object 179A for handling fax media, client object 179B for handling email 
media, and client object 179C for handling phone media. Client objects 179A, 179B, and 

15 179C correspond to fax service object 183 A, email service object 183B, and phone 
service object 183C, respectively. 

Fig. II shows two driver objects 189A, 189B instantiated in the channel driver 
120. Each driver object 189 A, 189B is designated for a different middleware server and 
includes resources specific to the type of middleware server. For example, driver object 
20 189A may use a TCP/IP connection to Middleware Server A and driver object 189B may 
have a direct connection to Middleware Server B. The service objects 183 created under 
each driver object 189A, 189B are specific to the middleware server with which the driver 
object 189 A, 189B is associated. 

There are several alternatives for implementing asynchronous notification of 
25 events from middleware servers to driver objects 189 including: 

1. Traditional TCP/IP socket. The driver objects 189 connect to the TCP/IP port 

of a middleware server. Events are sent through TCP/IP connection. 

2. OLE interface. One example is the IAdviseSink interface in OLE. 

3. Any other inter-process communication scheme. 
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With alternative 1, since the driver objects 189 can be implemented as a DLL, the 
driver object DLL either constructs a listening thread which blocks on select() call until 
the arrival of event, or a polling thread which periodically polls the middleware server for 
the arrival of event. Polling threads are useful for low-priority media types, e.g. email or 
5 fax, because polling periods typically last seconds or minutes. Polling threads are not as 
useful to detect high-priority media events, such as phone requests, because it is desirable 
to report the arrival of incoming call at anytime. Listening threads generate less network 
traffic than polling threads, and are generally useful for high priority and low priority 
media, however, some types of middleware servers do not support listening threads. 

10 To implement both polling threads and listening threads, a "task" thread is 

required in the driver object DLL. The "task" thread can be executed in driver objects 189 
as shown in Fig. 1J or in service objects 183 as shown in Fig. IK. 

Referring to Fig. 1 J, a task thread (or listen thread) implemented in the driver 
objects 189 may be "shared" by all service objects 183. For example, this listen thread 
15 can listen for all incoming events for all service objects 183. Once the listen thread 

receives an event, the listen thread then invokes and executes the event handling function 
implemented at service objects 183. 

Referring to Fig. IK, if the listen thread is implemented at the domain of service 
objects 183, every service object 183 constructs its own listen thread and the listen thread 
20 is not shared. Each listen thread [is] listens to a different target. For example, listen 

thread for user 1 listens for events on the first phone extension (ext. 1234), while the listen 
thread for user 2 listens for events on the second phone extension (ext. 5678). 

In one embodiment, client objects 179 are a collection of function pointers 
implemented by communication server 109 and passed to the service objects 183 for 
25 asynchronous event notification. In one implementation, when the listen thread in 
channel driver 120 receives an event, the following processes occur: 

1. Service object 183 invokes the HandleEvent() function implemented in 
corresponding client object 179. 

2. Client object 179 queues this event to a memory cache. 
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3. Client object 179 interrupts or signals the server thread 174 (Fig. ID) for 
Communication channel manager 177 to indicate the arrival of an event. Once 
this process is completed, the listen thread waits for the next event. 

4. During the next cycle of server thread 174, main thread sees an event is 
available in the memory cache. It dequeues the event out of the memory cache 
and continues the processing. 



Communication API Commands 



10 



Communication API 125 includes commands and data structures to allow third 
parties to develop applications that can integrate with client/server system 100. The data 
structures include arrays for passing data elements such as an agent's key value element, 
key value parameters, and string parameter lists. 
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25 



The following provide examples of runtime status flags that can be used in 
communication API 125: 



NOTSUPPORTED 

DISABLED 

CHECKED 



BLINKING 

NOP ARAMS OK 
STRP ARAMS OK 



= l; 

= 2; 
= 4; 



= 8; 



Command is not supported 
Command is disabled at this time 
Command is in "checked" state, for example when 
agent is in busy mode the "busy" command will be 
"checked" 

This is special effect flag to enable the blinking "answer 
call" command 
= 16; Command does not require any parameters to execute 
= 32; Command can be executed by providing single 
unnamed string parameters. Such commands are 
invoked when the agent types something in the edit 
control of the communication toolbar 105 and clicks 
the corresponding button. 



The following provide examples of commands that can be used in one 
embodiment of communication API 125: 



MediaType: The MediaType command is used from channel driver 120 to 

30 provide the media type. An indicator ofthe media type, such as the 

following examples of media type strings, is passed to the channel driver 

120 at the Create ISCDriverInstance() function: 

PHONECONTROL = 1 
CALLROUTING = 2 
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EMAIL =3 

FAX =4 

WEBCALL = 5 

WEB CHAT = 6 



5 CommandTypeEx: Channel driver 120 uses the CommandTypeEx function to 

request different services, such as making calls and sending messages, 
from communication server 109. 

ObjectType: The ObjectType function is used to monitor the communication 
objects, which can be represented by the following parameter values: 



10 



OB_LINK 


= 1 


SWITCH 


= 2 


QUEUE 


= 3 


TELESET 


= 4 


DN 


= 5 


AGENT 


= 6 


CALL 


= 7 


CALLROUT 


= 8 


EMAIL 


= 9 


FAX 


= 10 


WEBCALL 


= 11 


WEB CHAT 


= 12 


OTHERS 


= 1000 



ObjectProperty: The function ObjectProperty can be used to provide properties of 
monitored communication objects, such as: 

25 ONOFF =1 

AGENTID = 2 

NOTRE AD Y =4 

BUSY = 5 

DESCRIPTION =7 
30 TIMEINQUEUE =9 

QUEUEID = 12 

ISLOGON = 13 



Channel Driver Functions 



35 In one embodiment, driver objects 189 within each of channel drivers 120 can 

include the following functions: 
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FreeSCStrParamList is invoked by communications server 109 to release the 
memory which is initially allocated by channel drivers 120. 

RequestMediaTypeList is invoked by communications server 109 to query the list 
of media type strings supported by channel drivers 120. It can include the 
5 parameter mediaTypeList, which is a list of media-type strings. 



FreeSCStrParamList is invoked by communication server 109 to release memory. 

RequestCommandEventList is invoked to generate lists of commands and events 
that are implemented for a particular media type supported by the channel 
10 drivers 120. The parameters can include an input parameter specifying the 

media type, and output parameters that include lists of the commands and 
events. 

CreatelSCDriverlnstance is invoked to create a channel driver 120. The following 
parameters can be used: 

mediaTypeStr: the media-string that is defined by a particular driver 
implementation . 

languageCode: the language string, e.g. "ENU" for English, "FRA" for 
French, "DEU" for German, "PTB" for Portuguese-Brazilian, 
"ESN" for Spanish, "ITA" for Italian, and "JPN" for Japanese. 
connectString: the connect string for the channel driver 120 
datasetParams: the parameter list collected from the configuration 
handle: the handle to channel driver 120 returned by the channel driver 
120 

RequestService requests service object 183 from the channel driver 120. The 
25 following parameters can be used: 

clntlnterface: the interface at the client object 179 
connectString: the connect string for the service object 183 
datasetParams: the parameter list collected based on the configuration 
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serviceHandle: the handle to the service object 183 returned by the driver 
120 

ReleaselSCDriverlnstance is invoked by communication server 109 to release the 
driver object 189 specified by the driver handle supplied as a parameter. 

Service Object Functions 

In one embodiment, service objects 183 within each of channel drivers 120 can 
include the following functions: 

ReleaselSCServicelnstance is invoked to release the service object's handle. 

NotifyEventHandlingFinished is invoked by communications server 109 to notify 
the driver object 189 that the event handling is complete and the driver 
object 189 can move on or continue the process. This function is invoked 
to respond to HandleEvent's notifyWhenDone parameter. The following 
parameters can be used: 
Handle: identifier of the service object 183. 

trackingID: an identifier for the work item for which the communications 

server 109 was doing event handling, 
result: the result of event handling query of the list of media type strings 

supported by the channel driver 120. 

InvokeCommand is invoked by communications server 109 to invoke a driver 
command. The following parameter list can be used: 
Handle: identifier of the service object 

clntCmdTracklD: the unique ID for the InvokeCommand request 
name: the command name to invoke 

stringParam: the string from "Phone #" edit box on the toolbar 105 
datasetParam: the parameter list collected based on the configuration 

InvokeCommandEx is invoked by communications server 109 to invoke a certain 
type of command. The following parameter list can be used: 
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Handle: identifier of the service object. 

clntCmdTracklD : the unique ID decided by the communications server 

109 for this InvokeCommand request. 
commandType : the type of command the communications server 109 

wants to execute. 

datasetParam : the predefined parameter list set by the communications 
server 109. 

Release Workltem is invoked by communication server 109 to request release of a 
work item. Parameters can include: 
Handle: identifier of the service object. 
TrackingID: identifier of the work item. 

SuspendWorkltem is invoked by communication server 109 to request the service 
object 183 to suspend a work item. Parameters can include: 
Handle: identifier of the service object 183. 
TrackingID: identifier of the work item. 

ResumeWorkltem is invoked by communication server 109 to request the service 
object 183 to resume a work item. Parameters can include: 
Handle: identifier of the service object 183. 
TrackingID: identifier of the work item. 

HandleQueuedEvent is invoked by communication server 109 to pass an event 
previously queued in UQ system 102 to the service object 183 for 
handling. The channel driver 120 can treat this as an incoming media 
event from the middleware server. Parameters can include: 
Handle: identifier of the service object. 

name : the event name (from the original HandleEvent() call). 

fields : the event attributes list (from the original HandleEvent() call). 

trackingID : the unique ID for the media item. 

CancelQueuedEvent is invoked by communication server 109 to notify the 

channel driver 120 that a media-event is cancelled, released, or transferred 
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by UQ system 102. This function is the companion function of 
HandleQueuedEvent(). The following parameters can be used: 
Handle: identifier of the service object. 

name : the event name (from the original HandleEvent() call). 
5 trackingID : the unique ED for the media item. 



Client Object Functions 



The following are examples of functions that can be included in Client Objects 
179. The interface to these functions can be implemented with a function pointer so that 
driver objects 189 do not need to link to any libraries in communication server 109. 

10 ReleaseClientlnstance causes driver object 189 to release a client object's handle. 

BeginBatch and Endbatch are designed to save network overhead. The client 

object functions called between BeginBatch and EndBatch can be cached 

and sent out at the EndBatch call. These two functions can be used at the 

discretion of the driver object 189. For example, 

1 5 BeginBatch_Helper(clientInterf ace); 

CacheCommandInformation_Helper(clientInterface, ...); <— cached 
; ; ; ; // some processing 
if (error) 

HandleError_Helper(clientInterface, ...); <-- cached 
20 HandleEvent_Helper(clientInterface, ...); <— cached 

EndBatch_Helper(clientInterface); <— All requests will be sent out in 
one request 

*/ 

HandleEvent is used to handle the named event received from the channel driver 
25 120, using the given fields. By calling this method, the channel driver 120 

notifies the client objects 179 of the event, such as a call coming in on the 

monitored teleset. The following is the parameter list: 

Handle: identifier of the service object 183. 

name: the event name. 
30 fields: event attributes list. 
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notifyWhenDone: When set to TRUE, client objects 179 will invoke 

notifyEventHandlingFinished() to notify the driver 120 as soon as 
the event handling is done. 

trackingID : the ID uniquely identifies the work item that this event is 
5 associated with, e.g. call ID, email ID or web-chat session ID. 

ShowStatusText displays textual status information in the status line of the client 
objects 179. The following parameter list can be used: 
Handle: identifier of the service object 183. 
text: the text to display at the client status bar. 

10 HandleError handles asynchronous errors and logs them to an error log file. The 

following parameters can be used: 
Handle: identifier of the service object 183. 

clntCmdTracklD: if not 0, it is the same ,, clntCmdTrackID , ' value 
passed to InvokeCommand() to reflect the error caused by 
15 the request in InvokeCommand(). If it is 0, the error occurs 

out of context, 
error: the error text. 

CacheCommandlnformation is used to notify the client objects 179 about 
command status caching. The following parameters can be used: 
20 commandNames: list of command names. 

commandDescriptions: list of description text for each command, 
commands tatuses: list of status (CommandFlag) for each command. 

UpdateObjectlnformation is used to notify the client objects 179 about status 
change of objects. The following parameters can be used: 
25 trackingID: the ID uniquely identify the call that causes this information 

update. 

objectType: enumerated ObjectType value. 

objectID: the unique ID for this object. For phone, it is the extension. For 
email, it is the mailbox. For fax, it is the fax number. 
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datasetlnfo: the list of ObjectProperty values to update. For example, the 
list { {"4", "TRUE"}, {"9", "33"} } indicates ISNOTREADY is 
TRUE and TIMEINQ UEUE is 33 seconds. 

5 IndicateNewWorkltem notifies client objects 179 about the arrival of new inbound 

work item (e.g. call, email or fax) if the driver or the middleware supports 
a facility to change the work item's ID. The following parameters can be 
used: 

trackingID: the unique ID to identify the new work item. 
10 oldTrackingID: ID to identify the old ID. 

WorkltemStarted notifies client objects 179 that the agent has started working on 
one particular work item. This happens when (1) the agent answers a call 
and the call is connected, or (2) the agent accepts an email/fax work item. 
In response, client object 179 sets the work item identified by "trackingBD" 
15 as the active work item and starts tracking this work item. The agent will 

be treated as talking or working. The start time of this work item can be 
recorded by client objects 179. The following parameters can be used: 

trackingID: the unique ID to identify this work item. 
OldTrackingID: See the comment of the function IndicateNewWorkItem(). 
20 objectType: the object type. 

objectID: the media object for this work item. For phone, it is the 
extension. For email, it is the mail box. 
description: the description of work item. Driver implementation can 
use UpdateObjectlnformation to change the description of work 
25 item. 

startTime: the time the work item is started. 

WorkltemReleased is used to notify client objects 179 that a particular work item 
is released. This happens when (1) the agent releases a call and the call is 
! disconnected, or (2) the agent completes an email/fax work item. In 

30 response, client objects 179 stop tracking this work item and remove this 

work item. The following parameters can be used: 
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trackingID: the unique ID to identify the work item that is being released. 
stopTime: the time the work item is released/stopped. 

CleanAllWorkltems notifies client objects 179 that all work items stored in client 
objects 179 should be removed. 

5 WorkltemSuspended notifies client objects 179 that a work item is suspended. 

This can happen, for example, when (1) the agent puts a call to hold, or (2) 
the agent suspends an email/fax work item. The driver implementation 
calls this function when suspension is done. In response, client objects 179 
save the working context for this particular work item. The parameter 
10 trackingID can be used to identify the work item 

WorkltemResumed notifies client objects 179 that a suspended work item is 

resumed. This can happen, for example, when (1) the agent unholds a call 
and the call is retrieved, or (2) the agent resumes an email/fax work item. 
The driver objects 189 call this function when restoring is complete. In 
15 response, client objects 179 restore the working context(screen + work- 

tracking obj) and set the active work item as the one identified by 
"trackingID". The parameter trackingID can be used to identify the work 
item. 

Note that other functions and parameters can be included in communication API 
20 125 instead of, or in addition to, the functions listed herein. 

Universal Queuing System 

UQ system 102 queues requests for all types of media until an agent is assigned to 
the request. As agents become available, either by an agent logging in, finishing a task, or 
due to a change in state or assignment, UQ system 102 pushes a work item from a 
25 communication channel to an agent, and removes the work item from the respective 

queue. In one implementation, when multiple work items are routed to an agent, the work 
item that arrived first is presented to the agent and the other work item is returned to its 
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respective queue and rerouted/pushed to the next available agent that is capable of 
handling the particular work item. 

UQ system 102 includes UQ receiver 302 and UQ requester 304 that interface 
with UQ engine 306 via UQ server 308. Web server 146 can be included in system 100 to 
5 receive messages from UQ system 102. In one embodiment, web server 146 receives the 
message and sends it to EAI object manager 190. EAI object manager 190 packages the 
messages and transmits it to UQ business service 106. In other embodiments that do not 
include EAI object manager 190, the message can be sent directly to UQ business service 
106. 

10 UQ Business Service 

UQ system 102 interfaces with UQ business service 106 and web server 146 via 
UQ application programming interface (UQ API) 314. UQ business service 106 places 
information received from UQ system 102 into data structures used by communication 
server 109. UQ business service 106 also places information from communication server 
15 109 into data structures, commands, and parameters recognized and used by UQ API 314. 

In one embodiment, UQ business service 106 includes the following functions, 
with input and output parameters shown in parentheses, for initializing and 
communicating with the UQ system 102: 

UQOpenConnection (UQConfigurationName, Return) 
20 Provides UQ business service 106 with the necessary UQ configuration 

parameters to receive messages from communication server 109. The 
parameter "Return" in all of the UQ business service functions indicates 
status of the function upon return, for example, "0" means execution was 
successful. 

25 UQAssign (Return) 

Provides the UQ business service 106 with the necessary UQ configuration 
parameters to communicate with the communication server 109. 
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UQInitRules(Return) 

When UQOpenConnection is called, UQ business service 106 determines 
whether to upload rules, such as agent rules, and work item escalation 
rules. This function is called during the start-up of communication server 
5 109. If the rules are to be sent, this function retrieves route rules and 

escalation rules from a data table and packages them for transmission to 
UQ system 102. Once rules are downloaded to UQ system 102, the 
UQReplaceRules function is called to modify the rules. 

UQReplaceRules(Return) 
10 This function is called when the UQ rules need to be updated, such as 

when changes are made to a set of agent or escalation rules while 
communication server 109 is in operation. 

UQ Disconnect (Return) 

Commands UQ system 102 to terminate the connection between UQ 
15 system 102 and web server 146, and between UQ system 102 and 

communication server 109. This function is called when UQ system 102 
services are no longer needed. 

In one embodiment, UQ business service 106 also includes the following functions 
for initializing and maintaining agents: 

20 AgentLogon (AgentLogin, Return, AgentState) 

This function allows an agent to log into UQ system 102. Once the login is 
successful, agent is ready to receive work items. The AgentLogin 
parameter is the agent identification number assigned in communication 
server 109. The AgentState parameter is set to a value indicating the 

25 agent's state after the function is executed. 

AgentLogout (AgentLogin, Return, AgentState) 

This function allows an agent to log out of UQ system 102. Once the 
logout is successful, UQ system 102 will not queue any more work items 
for this agent. 
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AgentInitAuxwork(AgentLogin, Output) 

This function requests UQ system 102 to place the agent in AuxWork 
mode after all the current work items are completed. In AuxWork mode, 
agent will not receive more work but will remain logged in to the UQ 
5 system 102. 

AgentAvailable(AgentLogin, Return, AgentState) 

This function requests UQ system 102 to place the agent into available 
status. In the available state, the agent is ready to receive work items. 

RequestAgentMediaMode (AgentLogin, MediaType, Return, AgentMediaMode) 
10 This function allows clients 104 to request the agent state. 

Change AgentMediaMode (AgentLogic,Return, AgentMediaMode) 

This function allows clients 104 to change the media mode for an agent. 

ChangeAgentSkil (AgentLogin,Return) 

This function allows clients 104 to update the skill of an agent. After an 
15 agent's skill has been changed, this function should then be used to update 

UQ system 102 with the new agent skill. 

RequestAgentState (AgentLogin, Return, AgentState) 

To request UQ system 102 to report the current agent state. 

Request AgentWorkltemList (AgentLogin, Return, WorkltemID, MediaType, 
20 IsScheduledTask, ScheduleStartTime, ScheduleEndTime, AgentID, 

WorkltemState, WorkltemDataProperty) 

Request the UQ system 102 to return a list of all work items currently 

being handled by an agent. 

RequestAgentWorkableList (AgentLogin, Return, WorkltemID, MediaType, 
25 IsScheduledTask, ScheduleStartTime, ScheduleEndTime, AgentID, 

WorkltemState, WorkltemDataProperty) 
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This function requests UQ system 102 to return a list of possible work 
items for the agent. This function is used when the agent wants to pick a 
particular work item rather than being assigned to work items by UQ 
system 102. 

5 RequestWorkltemAssignment (AgentLogin, WorkltemID, Return) 

This function requests UQ system 102 to dispatch the specific work item to 
the agent if possible. If the work item is still available, the Return 
parameter code indicates SUCCESS and the work item will be delivered 
through communication server 109. 

10 RequestAgentMediaState (AgentLogin, Return, MediaType, AgentState, 

NumWorkltems) 

This function requests UQ system 102 to report the media (channel state) 
for each media that the agent is capable of handling. 

In one embodiment, UQ business service 106 also includes the following functions 
15 for initializing and maintaining work items: 

AddWorkltem (WorkltemID, MediaType, IsScheduledTask, ScheduleStartTime, 
ScheduleEndTiem, WorkltemDataProperty, Return) 

This function requests UQ system 102 to add the specific work item into 

the UQ system 102 for future dispatch. 



20 RequestWorkltemState (WorkltemID, Return, WorkltemState) 

This function requests the current state of a work item. 

AcceptWorkltem (WorkltemID, Return) 

This function allows clients 104 to tell UQ system 102 that the assigned 
work item has been accepted. As a result, agent state and work item state 
25 are updated by UQ system 102 to reflect the acceptance of the work item. 
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RejectWorkltem (WorkltemID, AgentLogin, Reason, Return) 

This function allows clients 104 to tell UQ system 102 that the assigned 
work item has been rejected. As a result, the work item will be sent back 
to the queue and the agent state for the channel will be set to AuxWork. 

5 CompleteWorkltem (AgentLogin, WorkltemID, Return) 

This function informs UQ system 102 that the work item is completed. 
The next state for the agent will depend on the Auto- Wrap setting, which 
can be set via a user interface such as toolbar 105. If Auto-Wrap is True, 
the agent is in Wrap mode and the work item will be in wrap mode. If 
10 Auto-Wrap is FALSE, the agent is placed back in the Available state. 

HoldWorkltem (AgentLogin, WorkltemID, Return, WorkltemState, 
New AgentS tate) . 

This function requests UQ system 102 to put a work item on hold status. 

UnHoldWorkltem (AgentLogin, WorkltemID, Return, WorkltemState, 
15 NewAgentState). 

This function requests UQ system 102 to take a work item off hold status. 

BlindTransferWorkltemToAgent (AgentLogin, WorkltemID, Return) 

This function transfers a work item to another agent. If the agent is not 
20 available, the work item can be queued for the agent. 

TransferWorkltemToAgent (AgentLogin, WorkltemID, Return) 

This function tells UQ system 102 to transfer the work item to the agent. If 
the agent is not available, UQ system 102 can inform the requesting agent 
25 that the work item is not deliverable. 

TransferWorkltemToRoute (AgentLogin, RoutelD, Return) 

This function transfers an agent to a route defined in the system 100 (Fig. 
1 A). A route represents a specific way to process the work item. 
30 Transferring a work item to a route redefines the characteristics of the 

work item and the way the work item should be handled. For example, the 
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work item was first believed to be best handled by agents with knowledge 
in one area and now find that it should be handled by an agent having 
knowledge in another area. Therefore, this work item is transferred to a 
route that can handle the work item. 

In one embodiment, UQ business service 106 includes the following functions for 
reporting performance statistics: 

SetChannelStatlnterval (Interval, Return) 

This function is used to set the feeding interval of the channel real time 
statistics. A predetermined default, such as 60 seconds, can be used. 
Statistics are transmitted to UQ business service 106 and logged into a 
table. 

Start AgentS tat (Interval, Return) 

This function is used to initiate the transmission of agent statistics. Data is 
logged to an agent statistics table. 

StopAgentStat (AgentLoginJReturn) 

This function is used to stop the transmission of agent statistics. 

In one embodiment, UQ business service 106 includes the following functions for 
handling work items: 

HandleWorkltem (AgentLogin, WorkltemED, MediaType, IsScheduleTask, 
ScheduleStartTime, ScheduleEndTime, AgentLogin, WorkltemState, 
DataProperty, MediaType, IsScheduleTask, ScheduleStartTime, 
ScheduleEndTime, AgentLogin, WorkltemState, DataProperty, Return) 

This function is used to inform a client that a work item is being assigned 

to an agent. 

HandleWorkltemStatus (WorkltemID, MediaType, IsScheduleTask, 
ScheduleStartTime, ScheduleEndTime, AgentLogin, WorkltemState, 
DataProperty, Return) 
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10 



This function is used to inform clients 104 that the status for the work item 
has been changed, so clients 104 can take any action that is necessary as a 
result. For example, work item status could be changed from alerting to 
complete because the other party abandoned the work item. In this case, 
clients 104 may have some housekeeping to perform. 

HandleAgentStateChange (AgentLogin, AgentState, Return) 

This function is used to inform UQ client that the state of the agent has 
been changed. 



HandleRouteStatisticsRequest (RouteStat, TotalWorkltems, AverageWaitTime, 
AverageServeTime, NlongestWaitTiem, OperationMode, Return) 

This function is used to inform clients 104 of the arrival of route statistics 
information. This method will handle the incoming statistics information, 
15 for example, by writing it to a database. 

HandleAgentStatisticsRequest (AgentLogin, TotalWorkltems, AverageServeTime, 
Average WrapTime, TotalAuxTime, TotalServingTime, TotalLoginTime, 
TotalServedWorkltem, Return) 
20 This function is used to inform the UQ client of the arrival of agent 

statistics information. This method will handle the incoming statistics 
information. Very likely the information will be written to a database. 

HandleError (MessageCode, Return) 
25 This function is used to inform UQ client that an error is received. 

Handle Alarm (MessageCode ,Return) 

This function is used to inform UQ client that an alarm is received. 

30 Handle Journal (WorkltemID, World temDataProperty, AgentStateHist, 

AgentLogin, AgentState, StartTime, EndTime, UQReasonCode, 
AgentReasonCode, EscHist, SzStep, StartTime, EndTime, UQReasonCode, 
AgentReasonCode, Return) 
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Journal of a work item to be sent to UQ client when the work item is 
completed. UQ client will log the journal into database. 



The foregoing lists are examples of functions that can be included in UQ business 
service 106. Other functions can be included in addition to, or instead of, these examples. 
5 Some of the functions include return codes and/or state codes to indicate whether a 

requested function was performed successfully and/or the state of UQ system 102, a work 
item, or an agent. The following lists provide examples of codes that are used as 
parameters in the preceding functions: 

Return Code 
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Error_Agent_Unable_To_Change_Skill 
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10 


Error_Queue_Not_Initialized 
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Error_Queue_Undefined 
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Error_Queue_Capacity_Exceeded 
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Error_Workitem_Adding_Failed 
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Error_Workitem_Failed_Change_State 


25 
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Logout 
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Busy 
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AuxWork 
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Media Mode 
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Busy 
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Wrap__Up 


40 


Operation Reason Code 
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Setting_Invalid_State 
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Agent_Not_Available 
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Route_Undefined 
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Work Item State 



1 


Active 


2 


Wrap_Up 


3 


Alerting 


4 


Completed 


5 


Queued 


6 


Scheduled 


7 


On_Hold 


8 


Received 



10 UQ Configuration 

Referring to Figs. 1 A-E and 3, clients 104 choose a UQ configuration via the 
UQOpenConnection function in UQ business service 106. UQ system 102 uses 
information such as "UQ receiver server name" and "UQ receiver Port" to determine 
where to send responses. In one embodiment, multiple receiver servers (not shown) in 
15 EAI object manager 190 can be connected to receive messages from UQ system 102, and, 
therefore, each receiver communicating with UQ system 102 sends a UQ configuration 
parameter in the UQOpenConnection function. 

Table 1 shows an example of parameters in a UQ configuration table that is stored 
in UQ system 102 and used to establish communication with and perform functions as 
20 requested by communication server 109 via the UQOpenConnection function. For 

example, Table 1 includes parameters for identifying and establishing communication 
with the host for UQ system 102. Table 1 also includes default settings for agent 
preferences such as whether an agent is in the auto-ready state after login or in the auto- 
auxwork state after login. 

25 Table 1: UQ Configuration Table 



Configuration Name 




UQ Host Name 


Identifier for host for UQ system 102 


UQ Host Port 


Address of host 


HTTPURLTempl ate 


Name of primary receiver server 


HTTPLoginURLTempl ate 




HTTPLogoutURLTemplate 




Business Service 


Specify the name of UQ business service 106 that 
will be invoked when outbound XML is sent. 


Method 


The name of method to be invoked in the UQ 
business service 106 mentioned above. 


MaxConnec ti on 


Maximum number of connections to be opened on 
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the primary receiver server. UQ system 102 has the 
option to send events to any of those open 
connections. By opening up multiple connections, 
multiple requests can then be processed. 


Transport 


Web server 146 and EAI object manager 190 
require: 

Name of server for UQ system 102 
Listening Port for UQ system 102 

Workflow process 144 requires: 
Name of server for UQ system 102 
Listening Port for UQ system 102 
Sender WorkFlow Name 
Send Method Name 


SecondaryHTTPURLTemplate 


For secondary UQ receiver server (optional). If 
included, this receiver server is used for primarily 
for non-time critical message such as alarm, error, 
statistics and journal. If no secondary receiver 
server is included, the primary receiver server in 
EAI object manager 190 can be used. 


SecondaryHTTPLogoutURLTempl 
ate 


Template for logout information 


SecondaryHTTPLoginURLTempla 
te 


Template for login information 


SkillBC:<Business Component 
Name> 


A Skill map that contains a list of skills and 
associated skill items for a client. Includes a list of 
business skills. For example, 

SkillBO:Industry = Industry 
SkillBO:Internal Product = Internal Product 
SkillBO:Language Def=Language Def 
SkillBO:Product Line=Product Line Briefing 


AuxWorkAfterLogin 


If "true", place the agent to Aux mode after login. 
Default is "true" 


LogoutFromAvailable 


If "true", allow agent to logout at Available state. 
Default is "true" 


WrapEnabled 


If "true", wrap state is valid for agent. Default is 
"true" 


Load Balancing 


If "true", Server Load Balancing is used and 
installed. Default is "false" 



Table 2 shows a subset of parameters in the UQ Configuration table in Table 1 
referred to as Propertylnfo parameters that are used in other functions that are included in 
UQ business service 106. 
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Table 2: Property Information Parameters 



Name 


Purpose 


UQ Host Name 




UQ Host Port 




HTTPURLTempl ate 


Template to be used in HTTP URL for login and 
making requests 


HTTPLoginURLTemplate 


Template to be use in HTTP for login 


HTTPLogoutURLTemplate 


String that needs to be included in the logout 
process 


MaxConnections 


Number of connections that need to be opened 


Secondary Receiver Host 




Secondary Receiver Port 




SecondaryHTTPURLTemplate 




SecondaryHTTPLogoutURLTempl 
ate 


String that needs to be included in the logout 
process 



Web server 146 handles packing information using a suitable data transfer 
protocol for outgoing messages to EAI object manager 190. In one implementation, for 
example, HTTP is used to communicate messages to and from UQ API 314. Web server 
5 146 converts information in HTTP format to another suitable transport protocol which 
EAI object manager 190 unpacks for use by UQ business service 106. In other 
embodiments, other protocols known in the art can be used instead of, or in addition to, 
HTTP. 

UQ Routing 

10 UQ engine 306 defines a route for processing each work item. For example, if a 

work item is a fax requiring response from an agent with knowledge of computer 
networking, the UQ engine 306 would define a route that specifies an agent with 
computer networking skills. An agent can transfer the work item to a route queue using 
the functions TransferWorkItemToRoute(Route configuration Name) or 

15 BlindTransferWorkltemToAgent(agentlD) if the agent is not able to respond to the work 
item. The skill requirements for the work item can be changed before invoking the 
transfer if the agent determines that a different skill is necessary to respond to the work 
item. 

In one embodiment, route points are generated, wherein each route point has 
20 specific skill requirements. When a work item is to be transferred to another point, the 
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transferring agent can choose a route point from a pop up list, for example. The list can 
include the option to either list all agents or all route points. 

UQ System Scenarios 

The following examples show how requests from clients are processed through 
5 one embodiment of system 100: 

Initialization and Rules Download 

Communication server background mode server 170 uses UQOpenConnection 
function in UQ business service 106 to connect clients with UQ system 102. In one 
embodiment, two or more configurations can be available to initialize UQ business 
10 service 106, including a default configuration. The default UQ configuration parameters 
are used if no other configuration specified. The UQPropertylnfo parameters of 
UQOpenConnection included PrimaryReceiverName and PrimaryReceiverPort which 
identify the location of the primary receiver server in web server 146. 

UQOpenConnection can be invoked multiple times to connect multiple receiver 
15 servers in web server 146 to UQ system 102, and UQ system 102 maintains a list of all 

connections to the connected receiver servers. After a successful UQOpenConnection, the 
function UQInitRules can be invoked to download agent skill information, as well as rules 
for escalating agents and specifying routes. In one embodiment, UQInitRules is invoked 
only once during initialization, and the function UQReplaceRules is used to update the 
20 rules once they have been initialized. The parameter ERROR JJQ_INITIALIZED 

indicates an error if UQInitRules if subsequently invoked. An indicator of whether the 
initialization was successful is supplied in the Return parameter associated with the 
UQInitRules function. 

Agent Logon 

25 New agents invoke UQOpenConnection through business service 106 to inform 

UQ system 102 that there is a new agent. The function AgentLogon is then invoked by 
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UQ business service 106 to log the agent into UQ system 102. UQ business service 106 
then sends a message that includes the agent skill information to UQ system 102. 

If multiple receiver servers are connected, each invocation of the function 
AgentLogon includes information about the receiver server that the agent is associated 
5 with. Agent information also includes information including auto-available setting and 
auto-wrap setting. UQ system 102 returns either the error if the invocation to 
AgentLogon fails, or returns the new agent state if the logon operation was successful. 

Email Arrival 

When communication server 109 receives an email message, it sends the message 
10 along with related information regarding the client who sent the message to UQ business 
service 106. UQ business service 106 transfers the email message and related information 
to UQ system 102 via the AddWorkltem function. UQ system 102 determines whether to 
accept the work item and issues a response to communication server 109 via web server 
146, EAI object manager 190, and UQ business service 106 indicating whether the work 
15 item was accepted using the status parameter in the HandleWorkltem function. 

UQ Delivers Work Item 

UQ system 102 determines an agent for a work item and sends a message that the 
work item was assigned to an agent to communication server 109 via the receiver server 
associated with the agent. UQ system 102 then transmits a message via the 
20 HandleWorkltem function to the receiver server associated with the agent. The 

ProcessEvents function in UQ business service 106 is then invoked to dispatch the 
message to an agent. The agent invokes the WorkltemAccept function to inform UQ 
system 102 that it received the work item. 

UQ System Issues An Alarm Or Error 

25 As an example of one method for UQ system 102 to notify communication server 

109 of an error or alarm, assume UQ system 102 determines that the number of requests 
that can be handled by one of the communication channels has exceeded a predefined 
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threshold. UQ system 102 sends a return code to the receiver server via the HandleError 
function indicating that the queue capacity has been exceeded. Web server 146 receives 
the message and invokes the function "ProcessE vents" in UQ business service 106. The 
error message can be logged and broadcast to the component that issued the request. 
Alarm messages are handled in a similar manner. The error/alarm can be broadcast 
visually, aurally, textually, and/or by any other suitable means known in the art. 

UQ System Sends Statistics To Communication Server 

A client or other component in system 100 (Fig. 1 A) can request statistics 
regarding its communication channels, agents, and/or the routing of agents, from UQ 
system 102 via SetChannelStatlnterval, StartAgentStat, and StopAgentStat functions. UQ 
system 102 generates the requested statistics and transmits them to Web server 146. 
When the receiver server in EAI object manager 190 receives the message, it can log the 
statistics and broadcast them through an interface such as a message bar mechanism, as 
known in the art. Agent configurations can be set up to request statistics on a continual 
basis. The statistics can include information for work items completed as well as work 
items in the agent's queue. 

Agent Accepts A Work Item 

When an agent is in AuxWork mode, the agent can choose a work item from the 
queue through a user interface such as the toolbar 105. When a work item is selected, UQ 
system 102 is notified via the RequestWorkableltemList function in business service 106. 
If the work item is available, the function will indicate a succesful selection through the 
return parameter and the work item is delivered via the HandleWorkltem function. The 
RequestWorkableltemList function can return an error indicator if the work item is not 
available for the agent. 

Call Routing 

When UQ system 102 receives a route request, UQ system 102 determines the 
agent to assign to the work item and sends a message to the agent's receiver server in EAI 
object manager 190 that includes the assigned agent and the work item. If UQ system 102 
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cannot find an agent to assign within the time allowed, the request is placed in a waiting 
queue as implemented by UQ engine 306. It is important to note that many different 
types of commercially available queuing engines 306 can be used in UQ system 102. 



Automated Call Distribution (ACD) Interaction With The UQ System 

5 Referring to Figs. 1 A-D and 3, an agent can be connected to receive calls directly 

from ACD switch 130E, without interacting with UQ system 102. Agents can also be 
connected to receive calls from ACD switch 130E as well as other work items through 
UQ system 102. This type of configuration is referred to auxiliary work mode (AuxWork 
mode). An agent can place themselves in the AuxWork state through an interface such as 
10 toolbar 105, or an administrator may configure the agent to enter the AuxWork state. 

In one implementation of AuxWork mode, ACD switch 130E dispatches a call to 
an agent, and the agent informs session mode communication server 110 when it answers 
the call. Session mode communication server 110 then relays the notice to UQ system 
102. At this point, UQ system 102 asks session mode communication server 110 to place 
15 the agent in the AuxWork state using, for example, the AgentlnitAuxwork function as 
described herein, after the agent finishes the call. 

When the agent finishes the call, it informs session mode communication server 
1 10 that the call is done, and the session mode communication server 1 10 in turn informs 
UQ system 102 that the call is finished. UQ system 102 then determines whether there is 

20 a suitable work item to assign to the agent based on the media channels in the agent's 

configuration. If a work item is available, the work item will be sent to the agent through 
the agent's receiver server in EAI object manager 190. The agent informs UQ system 102 
when it finishes the work item. If UQ system 102 determines that there are no more work 
items for the agent, it informs session mode communication server 1 10 to set the agent's 

25 ACD mode to ready to continue receiving calls through ACD switch 130E. 

There are several alternative implementations that can be used to place an agent in 
the AuxWork state. For example, an agent can default to AuxWork state. UQ system 102 
can be notified when ACD switch 130E receives a call that should be handled by the 
agent, and the agent notified to suspend processing a work item, such as a response to an 
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email request, to take the call. The agent notifies UQ system 102 when the call is 
completed, and returns to processing the suspended work item. 

Agent State Change 

When a work item is dispatched to an agent, the agent invokes the 
5 AcceptWorkltem function to accept the work item. Output parameters in 

AcceptWorkltem inform UQ system 102 of the new agent state and work item state. 
When the agent completes the work item, it invokes the Complete Workltem function to 
inform UQ system 102 of the new agent state and work item state. 

An auto-wrap option can be set in the agent's configuration table that allows an 
10 agent time to wrap up a work item upon completion. Agents can select an interface 

option that invokes the AgentAvailable function to indicate that they are out of wrap up 
mode and ready to accept another work item. UQ system 102 changes the status of the 
work item to Complete and places the agent in the Auxwork state if AgentlnitAuxWork 
function has been invoked. If the AgentlnitAuxWork function is not invoked, the agent's 
15 state is set to BUSY if there are other work items in the queue that the agent can handle. 
Otherwise the agent is placed in the Available state. 

Work Item Cancelled 

A situation can arise when a work item is cancelled after it has been assigned to an 
agent, but before the agent has accepted the work item. Such a situation may arise, for 
20 example, when a caller hangs up while waiting. In this case, the UQ system 102 informs 
the client that the work item is cancelled through Handle WorkltemStatus and a signal, 
such as a blinking button on the agent's user interface display, can be changed to indicate 
that the work item was removed. 

PBX And Email With PBX Higher Priority 

25 The term private branch exchange (PBX) refers to a subscriber-owned 

telecommunications exchange that usually includes access to the public switched network. 
When an email and a PBX work item are queued, UQ system 102 uses the priority set 
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forth in the route rules to determine which media will have higher priority over the other. 
Client configurations typically give PBX work items higher priority than email. 

Work Item Journal 

When a work item is completed, UQ system 102 sends a work item journal entry 
to communication server 109 via the HandleJournal function. The journal entry includes 
information to identify whether the journal entry pertains to the agent state history and/or 
the work item escalation history of the work item. 

System Failure 

If the connection between UQ system 102 and session mode communication 
server 110 fails, UQ system 102 will remove all agents associated with session mode 
communication server 1 10 and mark all work items as "Complete" with a failure error 
code. 

Multiple Requesters and Receivers 

When UQ business service 106 is instantiated, it will load the UQ configuration 
including the sender's server component name and the workflow name. In one 
embodiment, the sender server component is the EAI object manager 190, which is 
transparent to clients 104. If there are multiple instances of EAI object manager 190, 
communication server 109 routes the request to the appropriate component in 
communication server 109. A load balancer can be included to balance the load between 
multiple instances of EAI object manager 190. 

Each work item sent by UQ clients include a login and a client key associated with 
the work item. When the same work item is being returned form UQ system 102 as a 
result of either an agent assignment or problem with the work item, the login and the 
client key are used to route the result to the right client. 

Blind Transfer Of A Work Item To An Agent 
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An agent can use the function BlindTransferWorkltemToAgent to transfer a work 
item to another agent if the agent cannot respond to the work item, or thinks that another 
agent is better qualified to respond. If the transferree agent is not available to accept the 
work item being transferred, the work item will be queued until the agent is available. 

5 Consultative Transfer Of A Work Item To An Agent 

An agent can invoke the TransferWorkltemToAgent function to transfer a work 
item to another agent to consult with the other agent regarding the work item. If the agent 
is not available for consultation, UQ system 102 informs the agent that the other agent is 
not available. The agent can select whether to hold on to the work item, retry, or send the 
10 work item to a route. 

Transfer Work Item To A Route 

An agent can use the function TransferWorkltemToRoute to transfer a work item 
to along a route to another agent. This is useful, for example, when an agent receives a 
work item that would be handled more efficiently by an agent with other skills. 

15 UQ API 

In one embodiment, a client server system 100 (Figs. 1A-E) in accordance with 
the present invention includes UQ API 314 for communicating with UQ system 102. For 
example, the interface can translate information in one format, such as simplified object 
access protocol (SOAP) used by UQ business service 106 to an extensible markup 

20 language (XML) format used in UQ system 102. UQ API 314 can also translate 

information between other formats suitable for use in UQ business service 106 and UQ 
system 102. Alternatively, the same format can be used throughout system 100, thereby 
eliminating the need for UQ API 314. UQ API is further described in copending U.S. 
Patent Application Serial No. 09/823,678, Attorney Docket No. M-11538 entitled 

25 "Extensible Interface For Intermodule Communication", which application was filed on 
the same day is assigned to the same assignee as the present application and is 
incorporated by reference herein. 
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In one embodiment, a user interface for entering and editing agent skills is 
provided. An example of an agent skill graphical user interface (GUI) is described in U.S. 
Patent Application Serial No. 09/823,531, Attorney Docket No. M-l 1528 entitled 
"Communication Toolbar Supporting Multiple Communication Channels of Different 
Media Types", which application was filed on the same day and is assigned to the same 
assignee as the present application and is incorporated by reference herein. The agent 
skill GUI includes fields for selecting, entering and editing agent information including 
name, employee number, job title, login name, contact information, skills, and the level of 
expertise for each skill item. After a client updates the skills of an agent through the agent 
skill GUI, the ChangeAgentSkill function in UQ business service 106 can be used to 
update agent information in UQ system 102. 

UQ API Data Structures 

Figs. 4a-4m show tables representing data structures that are used in one 
embodiment of UQ API 314 for communicating information between UQ system 102 and 
communication server 109. 

Fig. 4a shows Table UQ_CFG which defines UQ system 102 configuration 
parameters such as the UQ server name, server port, receiver name, and receiver port. 
Fig. 4b defines Table UQ_CFG_PARAM which includes configuration parameters for 
UQ system 102 such as the configuration identifier, the name of the configuration. 

Fig. 4c is used for information pertaining to different routes defined for different 
media types, priority, and other characteristics. Fig. 4d further defines the data properties 
of a route. The characteristic of a route can be defined by one or more route properties. 
For example, an email will have "recipient", "subject" and category. A fax mail will be 
"DNIS" and "ANF\ These characteristics can be translated into skills. For example, 
"Recipient" = "Sales" can be translated into "Department" = "Sales". Another example is 
"DNIS"="8000" can be translated into "Product" = "NT". 

Fig. 4e defines how the processing of a work item can be escalated because the 
work item has not been served for a pre-defined period of time. Each escalation process 
defines a way that a work item should be processed. In general, the escalation process is 



747719 vl 



56 



Ser. No. 09/823,828 



to generalize the skill requirement of a work item so that the chance of having the work 
item served is improved. 

Fig. 4f defines the skill requirement for each escalation rule. Each rule generalizes 
the skill requirement of a work item. 

5 Fig. 4g is a map between route property and skill. For example, "DNIS" = "8000" 

could be translated into "Product" = "NT". This is basically a list of possible properties 
for each media. For example, email has subject, CC, recipient. PBX has ANI and 
Language. 

Fig. 4h represents the number of end points, also referred to as maximum number 
10 of sessions, for each media type that an agent is allowed. 

Figs. 4i-4k store route, media, and agent statistics information, respectively. In 
one embodiment, the statistics are sent from UQ system 102 to communication server 109 
at pre-defined time intervals as specified in the UQ configuration passed to UQ system 
102. An agent or administrator can also request statistics when desired through 
15 communication server 109. Some of the statistics, such as "Average Wait Time" are time 
dependent, and therefore, the time period is also included as part of the data. 

Fig. 41 stores the error log. 

Figs. 4m-4p store the processing history of each work item. 

Other tables can be included in an embodiment of UQ system 102 in addition to, 
20 or instead of, the tables shown in Figs. 4a-4p. 

An Examplary Computing and Network Environment 

Fig. 5 is a block diagram illustrating a network environment in which a 
client/server system 100 according to the present invention may be practiced. As is 
illustrated in Fig. 5, network 45, such as a private wide area network (WAN) or the 
25 Internet, includes a number of networked servers 25(1)-(N) that are accessible by client 
computers 35(1)-(N). Communication between client computers 35(1)-(N) and servers 
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25(1)-(N) typically occurs over a publicly accessible network, such as a public switched 
telephone network (PSTN), a DSL connection, a cable modem connection or large 
bandwidth trunks (e.g., communications channels providing Tl or OC3 service). Client 
computers 35(1)-(N) access servers 25(1)-(N) through, for example, a service provider. 
5 This might be, for example, an Internet Service Provider (ISP) such as America On- 
Line™, Prodigy™, CompuServe™ or the like. Access is typically had by executing 
application specific software (e.g., network connection software and a browser) on the 
given one of client computers 35(1)-(N). 

It will be noted that the variable identifier "N" is used in several instances in Fig. 5 
to more simply designate the final element (e.g., servers 25(1)-(N) and client computers 
35(1)-(N)) of a series of related or similar elements (e.g., servers and client computers). 
The repeated use of such variable identifiers is not meant to imply a correlation between 
the sizes of such series of elements, although such correlation may exist. The use of such 
variable identifiers does not require that each series of elements has the same number of 
elements as another series delimited by the same variable identifier. Rather, in each 
instance of use, the variable identified by "N" may hold the same or a different value than 
other instances of the same variable identifier. 

One or more of client computers 35(1)-(N) and/or one or more of servers 25(1)- 
(N) may be, for example, a computer system of any appropriate design, in general, 
20 including a mainframe, a mini-computer or a personal computer system. Such a computer 
system typically includes a system unit having a system processor and associated volatile 
and non- volatile memory, one or more display monitors and keyboards, one or more 
diskette drives, one or more fixed disk storage devices and one or more printers. These 
computer systems are typically information handling systems which are designed to 
25 provide computing power to one or more users, either locally or remotely. Such a 
computer system may also include one or a plurality of I/O devices (i.e., peripheral 
devices) which are coupled to the system processor and which perform specialized 
functions. Examples of I/O devices include modems, sound and video devices and 
specialized communication devices. Mass storage devices such as hard disks, CD-ROM 
30 drives and magneto-optical drives may also be provided, either as an integrated or 
peripheral device. One such example computer system, discussed in terms of client 
computers 35(1)-(N) is shown in detail in Fig. 6. 



10 
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Fig. 6 depicts a block diagram of a computer system 10 suitable for implementing 
the present invention, and example of one or more of client computers 35(1)-(N). 
Computer system 10 includes a bus 12 which interconnects major subsystems of computer 
system 10 such as a central processor 14, a system memory 16 (typically RAM, but which 
5 may also include ROM, flash RAM, or the like), an input/output controller 18, an external 
audio device such as a speaker system 20 via an audio output interface 22, an external 
device such as a display screen 24 via display adapter 26, serial ports 28 and 30, a 
keyboard 32 (interfaced with a keyboard controller 33), a storage interface 34, a floppy 
disk drive 36 operative to receive a floppy disk 38, and a CD-ROM drive 40 operative to 
10 receive a CD-ROM 42. Also included are a mouse 46 (or other point-and-click device, 
coupled to bus 12 via serial port 28), a modem 47 (coupled to bus 12 via serial port 30) 
and a network interface 48 (coupled directly to bus 12). 

Bus 12 allows data communication between central processor 14 and system 
memory 16, which may include both read only memory (ROM) or flash memory (neither 

15 shown), and random access memory (RAM) (not shown), as previously noted. The RAM 
is generally the main memory into which the operating system and application programs 
are loaded and typically affords at least 16 megabytes of memory space. The ROM or 
flash memory may contain, among other code, the Basic Input-Output system (BIOS) 
which controls basic hardware operation such as the interaction with peripheral 

20 components. Applications resident with computer system 10 are generally stored on and 
accessed via a computer readable medium, such as a hard disk drive (e.g., fixed disk 44), 
an optical drive (e.g., CD-ROM drive 40), floppy disk unit 36 or other storage medium. 
Additionally, applications may be in the form of electronic signals modulated in 
accordance with the application and data communication technology when accessed via 

25 network modem 47 or interface 48. 

Storage interface 34, as with the other storage interfaces of computer system 10, 
may connect to a standard computer readable medium for storage and/or retrieval of 
information, such as a fixed disk drive 44. Fixed disk drive 44 may be a part of computer 
system 10 or may be separate and accessed through other interface systems. Many other 
30 devices can be connected such as a mouse 46 connected to bus 12 via serial port 28, a 
modem 47 connected to bus 12 via serial port 30 and a network interface 48 connected 
directly to bus 12. Modem 47 may provide a direct connection to a remote server via a 
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telephone link or to the Internet via an internet service provider (ISP). Network interface 
48 may provide a direct connection to a remote server via a direct network link to the 
Internet via a POP (point of presence). Network interface 48 may provide such 
connection using wireless techniques, including digital cellular telephone connection, 
5 Cellular Digital Packet Data (CDPD) connection, digital satellite data connection or the 
like. 

Many other devices or subsystems (not shown) may be connected in a similar 
manner (e.g., bar code readers, document scanners, digital cameras and so on). 
Conversely, it is not necessary for all of the devices shown in Fig. 6 to be present to 

10 practice the present invention. The devices and subsystems may be interconnected in 
different ways from that shown in Fig. 6. The operation of a computer system such as 
that shown in Fig. 6 is readily known in the art and is not discussed in detail in this 
application. Code to implement the present invention may be stored in computer-readable 
storage media such as one or more of system memory 16, fixed disk 44, CD-ROM 42, or 

15 floppy disk 38. Additionally, computer system 10 may be any kind of computing device, 
and so includes personal data assistants (PDAs), network appliance, X-window terminal 
or other such computing device. The operating system provided on computer system 10 
may be MS-DOS®, MS-WINDOWS®, OS/2®, UNIX®, Linux® or other known 
operating system. Computer system 10 also supports a number of Internet access tools, 

20 including, for example, an HTTP-compliant web browser having a JavaScript interpreter, 
such as Netscape Navigator® 3.0, Microsoft Explorer® 3.0 and the like. 

Moreover, regarding the signals described herein, those skilled in the art will 
recognize that a signal may be directly transmitted from a first block to a second block, or 
a signal may be modified (e.g., amplified, attenuated, delayed, latched, buffered, inverted, 

25 filtered or otherwise modified) between the blocks. Although the signals of the above 
described embodiment are characterized as transmitted from one block to the next, other 
embodiments of the present invention may include modified signals in place of such 
directly transmitted signals as long as the informational and/or functional aspect of the 
signal is transmitted between blocks. To some extent, a signal input at a second block 

30 may be conceptualized as a second signal derived from a first signal output from a first 
block due to physical limitations of the circuitry involved (e.g., there will inevitably be 
some attenuation and delay). Therefore, as used herein, a second signal derived from a 
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first signal includes the first signal or any modifications to the first signal, whether due to 
circuit limitations or due to passage through other circuit elements which do not change 
the informational and/or final functional aspect of the first signal. 



The foregoing described embodiment wherein the different components are 
5 contained within different other components (e.g., the various elements shown as 
components of computer system 10). It is to be understood that such depicted 

architectures are merely examples, and that in fact many other architectures can be 

■i 

implemented which achieve the same functionality. In an abstract, but still definite sense, 
any arrangement of components to achieve the same functionality is effectively 

10 "associated" such that the desired functionality is achieved. Hence, any two components 
herein combined to achieve a particular functionality can be seen as "associated with" 
each other such that the desired functionality is achieved, irrespective of architectures or 
intermediate components. Likewise, any two components so associated can also be 
viewed as being "operably connected", or "operably coupled", to each other to achieve the 

15 desired functionality. 

Fig. 7 is a block diagram depicting a network 50 in which computer system 10 is 
coupled to an internet 60, which is coupled, in turn, to client systems 70 and 80, as well as 
a server 90. Internet 60 (e.g., the Internet) is also capable of coupling client systems 70 
and 80 and server 90 to one another. With reference to computer system 10, modem 47, 

20 network interface 48 or some other method can be used to provide connectivity from 
computer system 10 to internet 60. Computer system 10, client system 70 and client 
system 80 are able to access information on server 90 using, for example, a web browser 
(not shown). Such a web browser allows computer system 10, as well as client systems 
70 and 80, to access data on server 90 representing the pages of a website hosted on server 

25 90. Protocols for exchanging data via the Internet are well known to those skilled in the 
art. Although Fig. 7 depicts the use of the Internet for exchanging data, the present 
invention is not limited to the Internet or any particular network-based environment. 

Referring to Figs. 1, 2 and 3, a browser running on computer system 10 employs a 
TCP/IP connection to pass a request to server 40, which can run an HTTP "service" (e.g., 
30 under the WINDOWS® operating system) or a "daemon" (e.g., under the UNIX® 
operating system), for example. Such a request can be processed , for example, by 
contacting an HTTP server employing a protocol that can be used to communicate 
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between the HTTP server and the client computer. The HTTP server then responds to the 
protocol, typically by sending a "web page" formatted as an HTML file. The browser 
interprets the HTML file and may form a visual representation of the same using local 
resources (e.g., fonts and colors). 

5 The foregoing detailed description has set forth various embodiments of the 

present invention via the use of block diagrams, flowcharts, and examples. It will be 
understood by those within the art that each block diagram component, flowchart step, 
and operations and/or components illustrated by the use of examples can be implemented, 
individually and/or collectively, by a wide range of hardware, software, firmware, or any 
10 combination thereof. 

The present invention has been described in the context of a fully functional 
computer system, however those skilled in the art will appreciate that the present 
invention is capable of being distributed as a program product in a variety of forms, and 
that the present invention applies equally regardless of the particular type of signal 
15 bearing media used to actually carry out the distribution. Examples of signal bearing 
media include: recordable type media such as floppy disks and CD-ROM, transmission 
type media such as digital and analog communications links, as well as media storage and 
distribution systems developed in the future. 

The above description is intended to be illustrative of the invention and should not 
20 be taken to be limiting. Other embodiments within the scope of the present invention are 
possible. Those skilled in the art will readily implement the steps necessary to provide the 
structures and the methods disclosed herein, and will understand that the process 
parameters and sequence of steps are given by way of example only and can be varied to 
achieve the desired structure as well as modifications that are within the scope of the 
25 invention. Variations and modifications of the embodiments disclosed herein can be 

made based on the description set forth herein, without departing from the spirit and scope 
of the invention as set forth in the following claims. 
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ADAPTIVE COMMUNICATION APPLICATION PROGRAMMING 

INTERFACE 



5 Mingtse Chen 

Anil K. Annadata 
Leon Chan 

Cross-Reference To Related Applicatioris Application 

10 The present invention is related to the subject matter of the following provisional 

United States Patent Application: "Adaptive Communication and Communication 
Server," naming inventors Henry Jay and Anil Annadata, filed February 6, 2001, 
Attorney Docket No. 5306.P012Z. Applicants hereby claim the benefit under 35 U.S.C. 
§ 119(e) of the foregoing-referenced provisional application. The foregoing-referenced 

15 provisional patent application is hereby incorporated by reference herein in its entirety. 

Background 

In today's emerging technological and information world, companies are 
interacting with their customers, potential customers and other contacts through a wide 

20 variety of different communication channels. Such communication channels include 
face-to-face, telephone, fax, email, voicemails, wireless communication, Internet 
information inquiries via call me now and call me later, Internet collaborative sessions, 
paging and short messaging services. With all these communication channels, 
companies are faced with managing each customer interaction while meeting service 

25 levels and maximizing customer satisfaction. In addition, companies are faced with 
optimally staffing and training their workforce to deal with customers through these 
communication channels whether through their customer support center(s), telebusiness 
organizations, or their sales, marketing, and service professionals. 

Currently, many companies have dedicated email inboxes, fax inboxes, and 
30 voicemail boxes defined for specific business areas as well as automated call 

distributors. Employees called agents are assigned to poll and manage the support 
requests from customers for each communication channel. Combined with the 
traditional call queues for inbound telephone calls, each agent is tasked with managing 
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his or her work using all these communication channels while not having any visibility to 
the queue status and priorities of each customer support request and/or communication 
channel. 

Thus, it is desirable to provide a system that includes a universal queue strategy 
capable of assigning, routing, and queuing work items from multiple channels of 
communications to an agent having the appropriate skills to respond to the request. The 
system should enable the agent to view and manage his or her work items for all 
communication channels. Such a system reduces the response times and increases 
customer satisfaction, while balancing priorities amongst work items in multiple 
communication channels. 

Summary 

In one embodiment, a method for inter-module communication is disclosed. The 
method includes defining a command definition, wherein the command definition 
comprises commands for interfacing with a multi-channel, multi-media, communication 
queuing system. 

In one aspect, this embodiment includes driver object commands for requesting 
media type lists and command event lists, creating driver objects, requesting service, and 
releasing driver objects. 

In another aspect, this embodiment includes service object commands for 
releasing service objects, notifying when handling of an event is complete, invoking 
commands, releasing work items, suspending work items, resuming work items, handling 
queued events, and canceling queued events. 

In another aspect, this embodiment includes client object commands for starting a 
work item, releasing work items, saving work item contexts, restoring work item contexts, 
serializing work items, freeing work item storage, beginning batch processing, and ending 
batch processing. 
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In another embodiment, a inter-module communication definition is disclosed. 
The definition includes a command definition, wherein the command definition comprises 
commands for interfacing with a multi-channel, multi-media, communication queuing 
system. 

5 In one aspect of this embodiment, the command definition includes driver object 

commands to request media type lists and command event lists, create drivers, request 
service, and release drivers. 

In another aspect of this embodiment, the command definition includes service 
object commands to release service objects, notify when handling of an event is complete, 
10 invoke commands, release work items, suspend work items, resume work items, handle 
queued events, and cancel queued events. 

In another aspect of this embodiment, the command definition includes client 
object commands to start a work item, release work items, save work item contexts, 
restore work item contexts, serialize work items, free work item storage, begin batch 
15 processing, and end batch processing. 

The foregoing is a summary and thus contains, by necessity, simplifications, 
generalizations and omissions of detail; consequently, those skilled in the art will 
appreciate that the summary is illustrative only and is not intended to be in any way 
limiting. As will also be apparent to one of skill in the art, the operations disclosed herein 
20 may be implemented in a number of ways, and such changes and modifications may be 
made without departing from this invention and its broader aspects. Other aspects, 
inventive features, and advantages of the present invention, as defined solely by the 
claims, will become apparent in the non-limiting detailed description set forth below. 

Brief Description of the Drawings 

25 The present invention may be better understood, and its numerous objects, 

features, and advantages made apparent to those skilled in the art by referencing the 
accompanying drawings. 

Figs. 1 A through ID are a diagram of one embodiment of a system for enabling 
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and scheduling agents to respond to customer support requests and/or information 
requests via multiple communication channels of different media types. 

Fig. IE is a diagram of another embodiment of a system for enabling and 
scheduling agents to respond to customer support requests and/or information requests 
5 via multiple communication channels of different media types. 

Fig. IF is a diagram of components included in an implementation of a 
communication application programming interface. 

Fig. 1G is a diagram of components included in another implementation of a 
communication application programming interface. 

10 Fig. 1H is a diagram of components included in another implementation of a 

communication application programming interface. 

Fig. II is a diagram of components included in another implementation of a 
communication application programming interface. 

Fig. 1 J is a diagram of components included in another implementation of a 
15 communication application programming interface. 

Fig. IK is a diagram of components included in another implementation of a 
communication application programming interface. 

Fig. 2 shows an example of a database scheme for the system of Figs. 1 A through 

ID. 

20 Figs. 2a through 2cc show examples of tables corresponding to table names in 

Fig. 2. 

Fig. 3 shows one embodiment of a universal queuing system in accordance with 
the present invention. 

Figs. 4a through 4p show examples of tables in a universal queuing database in 
25 accordance with the present invention. 
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Fig. 5 is a block diagram illustrating a network environment in which a system 
for enabling and scheduling agents according to embodiments of the present invention 
may be practiced. 

Fig. 6 is a block diagram illustrating a computer system suitable for 
5 implementing embodiments of the present invention. 

Fig. 7 is a block diagram illustrating the interconnection of the computer system 
of Fig. 6 to client and host systems. 

The use of the same reference symbols in different drawings indicates similar or 
identical items. 

10 Detailed Description 

Figs. 1 A through ID are a diagram of one embodiment of a client/server system 
100 for enabling agents to respond to customer support requests and/or information 
requests via multiple communication channels of different media types. These media 
types include, but are not limited to, telephone, email, fax, web collaboration, Internet 
15 call me now and call me later, web chat, wireless access protocol, paging, and short 

messaging services. The term customer is used herein to include individuals and contact 
persons at businesses that are customers of the company, potential customers and other 
persons with whom a customer support agent communicates. 

Fig. 1 A shows that four customers have submitted customer support requests to 
20 the client/server system 100 and three agents are one agent is responding to customer 

support requests. The four customers submitted the customer support requests via four 
communication channels 130, such as communication channels 130A, 130B, 130C, and 
130D. In one embodiment, at least two of the four communication channels support 
different media types. 

25 In accordance with the present invention, client/server system 100 includes a 

universal queuing (UQ) system 102 capable of assigning, routing, and queuing work 
items from multiple channels of communication to an agent having the appropriate skills 



747719 vl 



Ser. No. 09/823,828 



to respond to a customer support request. The term work item refers to a request from a 
customer that requires a response from an agent assigned by client/server system 100, 
such as responding to a customer support request in the form of a telephone call, email, 
fax or other communication of a different media type. A work item can be initiated 
5 when an event such as an incoming customer support request arrives or by an agent 
using a user interface to client/server system 100. 

Client/server system 100 also includes a communication server 109 that enables 
agents to use communication channels of different media types to communicate with 
customers. Communication server 109 handles events such as the arrival of incoming 
10 customer support requests from a channel driver 120 such as one of channel drivers 

120A, 120B, and 120C. Each channel driver 120 communicates with a communication 
channel 130 such as one of communication channels 130A, 130B, 130C and 130D. 

Interaction between UQ system 102 and communication server 109 occurs when, 
for example, communication server 109 receives and routes an incoming customer 
15 request as a work item to UQ system 102 for assignment to an agent. UQ system 102 

assigns an agent to the work item and sends the work item back to communication server 
109 for communication to the assigned agent. 

Web browser client 104A includes a web browser program such as Microsoft's 
Internet Explorer running on a client computer system (not shown). The web browser 

20 client 104 A communicates with a web server 188. Application server 126 in 

client/server system 100 performs functions for and sends information to web browser 
client 104A via web server 188, which provides web pages for web browser client 104A 
to display. Web server 188 can download program instructions, such as Java applet 116, 
to the web browser client 104A to provide, additional functionality, such as a user 

25 interface. 

Web browser client 104A is shown including a toolbar 105. One of skill in the 
art will recognize that other user interfaces providing the functionality of toolbar 105 can 
be implemented using a variety of different display formats to interface with multiple 
communication channels of different media types within the scope of the invention. 
30 Toolbar 105 is presented as part of a user interface. 
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In one embodiment, application server 126 of client/server system 100 includes 
object manager 107, session mode communication server 110, request mode 
communication server 140, inbound communication receiver 170, UQ system 102, web 
server 188, web server 146, Enterprise Application Interface (EAI) object manager 190, , 
5 and workflow process 144. In one embodiment, communication between components in 
application server 126 is enabled using a suitable inter-process communication protocol 
in conjunction with transfer control protocol/Internet protocol (TCP/IP) as known in the 
art. 



UQ business service 106 allows communication server 109 to request 
10 information from UQ system 102, which returns the information via web server 146, and 
EAI object manager 190. In one embodiment, both session mode communication server 
110 and inbound communication receiver 170 can communicate with UQ system 102. 
Other embodiments can communicate with a third party queuing system for maintaining 
work item queues and assigning agents to work items. 

15 Communication server 109 includes session mode communication server 110. 

Communication server 109 may optionally include one or both of request mode 
communication server 140 and inbound communication receiver 170. It is important to 
note that the functionality provided by servers 110, 140, and 170 can be implemented on 
one server computer system or distributed across two or more server computer systems. 

20 Communication server 109 handles all communication between agents and customers via 
communication channels 130 of one or more media types. Communication server 109 is 
not media-specific and has no knowledge of communication channels or media. 

To communicate with multiple communication channels of different media types, 
communication server 109 is designed to communicate with a channel driver 120 such as 

25 one of channel drivers 120A, 120B, and 120C. A channel driver 120 is written 

according to Communication Application Program Interface (API) 125. Communication 
API 125 provides an interface for third party vendors of communication devices and 
software (e.g., middleware vendors for communication devices) to provide a channel 
driver 120 so that their products are compatible with application server 126. By 

30 implementing a channel driver 120, vendors can take advantage of the customer support 
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center management features and multi-media communication channel capabilities of 
application server 126. 

Communication API 125 is designed to provide flexibility to third party vendors 
for integrating their products. In the implementation of a channel driver, a vendor 
5 defines the commands the vendor's communication channel 130 understands so that 
communication server 109 can issue commands for the communication channel 130 to 
perform. Normally these commands are issued when session mode communication 
server 110 is presenting a user interface to the agent, although inbound communication 
receiver 170 also can send commands in some circumstances. 

10 In addition, the vendor defines the events that the vendor's communication 

channel 130 provides regarding activity of a specific communication channel 130. 
Finally, the vendor provides a channel driver 120 implementation, such as a dynamic 
link library (.DLL file), for performing each command and generating and providing 
each event. The channel driver 120 implementation is required by communication API 

15 125 to include code to instantiate a driver object and at least one service object. 

By requiring the vendor to provide facilities for the communication server 109 to 
issue commands to and to receive information from the vendor's communication channel 
130, communications API 125 enables communications server 109 to operate 
independently of the command channel 130 media type and specific protocols to 
20 communicate with the vendor's communication device or software. 

Referring to Fig. 2, an example of a database schema 200 that can be used by 
client/server system 100 (Fig. 1 A) for storing and communicating channel driver 
information, agent limitations on media access, commands and events, inbound task 
management, agent preferences, agent status, media status, communication channel 
25 configurations, multiple queue support, and agent management is shown. Database 

schema 200 includes data structures for configuration base 202, command and event 204, 
system base 206, response group 208, and email profile access control 210. 

Figs. 2a through 2cc show examples of tables corresponding to table names in 
Fig. 2. Note that Fig. 2 does not indicate all of the relationships between the tables for 
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simplicity, and that many instances of a table may exist for a particular configuration, 
depending on the number and types of communication channels authorized. 
Additionally, one skilled in the art will realize that this collection of tables, the 
parameters included in each table, and the storage space allowed for the parameters, is 
5 one example of how the database schema may be configured, and that other suitable 
arrangements can be used in accordance with the present invention. 

The tables in Figs. 2a, 2b, 2c, and 2d are part of system base 206 and store 
channel driver information and channel driver parameters. The tables of Figs. 2a and 2b 
store the general information for a channel driver, such as channel drivers 120A, 120B, 

10 and 120C, and can be used by any customer support center configuration. The typical 

data stored in these tables are the file name of the channel driver DLL, the media type of 
the associated communication channel 130 (e.g. email, fax, etc.), a media string which is 
used by communication server 109 at run time to invoke a media service for the channel 
driver, the complete list of channel driver parameters, and the default value for each 

1 5 channel driver parameter. The parameters INB OUND_FLG and OUTBOUNDJFLG of 
table CNCTR (Fig. 2a) indicate whether the channel driver 120 supports inbound and/or 
outbound communications. 

Customer support centers can establish configurations that define the groups of 
agents that have similar requirements to communicate, therefore requiring access to the 

20 same communication channel 130. For example, salespersons within a company may 
need the ability to communicate via wireless access protocol, whereas telephone 
operators may not. A configuration can be established for each group within the 
company. A channel driver profile allows more than one customer support center 
configuration to share a single channel driver 120, with each additional channel driver 

25 profile overriding the values of some channel driver parameters such as the location of 
the channel driver DLL. For example, due to the network architecture of the company, 
salespersons for the company in Phoenix may use a different channel driver 120 than 
salespersons in Palo Alto. A channel driver profile will enable the Phoenix and Palo 
Alto salespersons to use the same channel driver but point to different DLLs. The term 

30 channel driver 120 is used herein to include at least one channel driver profile providing 
default values for the channel driver parameters. 
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The tables in Figs. 2c and 2d store the channel driver profile for a particular 
customer support center configuration and the channel driver profile is not shared or 
used by other customer support center configurations. Typically, an administrator uses 
the table CNCTR_PARM to override a default value for a channel driver parameter for 
5 the particular customer support center configuration. Referring to Fig. 2a, the string 
stored in the variable CNCTR_MEDIA_STR is based on a list of names of 
communication media supported by the channel driver 120. An administrator enters the 
name of the media in the CNCTR_MEDIA_STR field in character string format. The 
string stored in this field is used to determine the channel driver 120 to issue a command 
10 or from which an event originated. If one channel driver 120 supports multiple types of 
communication media, the administrator creates one record for each media type. The 
following examples show the parameters in the CNCTR table for telephone, email, and 
web chat media: 

{"XYZ Phone Driver", 'Telephone", "xyz.dll", "Y", "Y", "XYZ Phone 
15 Implementation",, "N"}, 

{"XYZ Email Driver", "Email", "xyz.dll", "Y", "Y", "XYZ Email 
Implementation",, "N"}, 

{"XYZ Web Chat Driver", "Web Chat", "xyz.dll", "Y", "Y", "XYZ Web-Chat 
Implementation",, "N" } 

20 Note that when a work item is submitted to UQ system 102 (Fig. 1A) for agent 

assignment, the CNCTR_MEDIA_STR is also passed with the work item to help UQ 
system 102 to identify an agent with skills in using that media type. 

An example of an algorithm for determining the list of channel drivers 120 for a 
particular agent is as follows: 
25 1. Determine the configuration ID for the agent by searching AGENT table (Fig. 

2j). 

2. For the configuration ID, search the CFG_PROF table (Fig. 2o) for the list of 
channel driver profiles associated with the configuration. 

3. For each of channel drivers 120, load the channel driver information and 
30 channel driver parameters from CNCTR, CNCTR_PARM, PROF, and PROF JP ARM 

tables (Figs. 2a-2d, respectively). 



747719 vl 



11 



Ser. No. 09/823,828 



An example of an algorithm for loading a list of channel drivers 120 upon the 
agent logging in to client/server system 100 is as follows: 
1. For each of channel drivers 120, 



a. 



If the DLL has not loaded, load the DLL 



5 



b. 



Pass the channel driver parameters and ask the channel driver for the 
handle of a driver object. 



c. 



Request the handle of a service object by passing the media type of the 
channel driver identified in CFG_PROF (Fig. 2o) as being 
associated with the agent. 



10 



2. End loop 



By default, an agent is authorized to access all channel drivers 120 associated 
with the configuration to which the agent belongs. For example, if the agent belongs to 
"Customer support center 1," all channel driver profiles configured in "Customer support 
center 1" are accessible for all agents in "Customer support center 1" by default. The 
15 administrator can further limit the agent's access to channel drivers 120 using table 
AGENT_LIM (Fig. 2m) that lists the channel driver profiles the agent cannot access. 

Agent preferences are stored in table AGENT_PREF (Fig. 2e) in a centralized 
database so that an agent's settings are available independently of the type of client or 
communication channel being used. A user interface for modifying the settings is also 
20 supplied in an embodiment of the present invention. 

Embodiments of the present invention support multiple communication media 
channels and agent assignment with UQ system 102 (Fig. 1A). Table AGENT_STAT 
(Fig. 2f) stores the current working status of a particular agent for all types of media that 
the agent is authorized to use. From this table, the administrator can see a list of media 
25 types that agent is currently authorized to access and the status of each media type. 

When the "NOT_READY_FLG" parameter in table AGENT_STAT (Fig. 2f) 
indicates that an agent is not ready to take work items, UQ system 102 (Fig. 1A) will not 
assign any work items to the agent. The "BUSY_FLG" parameter indicates that the agent 
is busy. 
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Table AGENT_STAT is updated mainly at run time. When the agent first logs 
on using the user interface, one record for each media type that the agent is authorized to 
access is created. For example, 

{"agent_emp_id", "Phone Control", "", "", "1234", ""}, 
5 { "agent_emp__id", "Email/Fax", "", "", "1234", "" } , 

{"agent_emp_id", "Web Chat", "", "", "1234", ""} 

The records are updated according the agent's working status. For example 
{"agent_emp_id", "Phone Control", "Y", "", "1234", "Y"} indicates that agent 

is not ready but is talking on the phone, 
10 {"agent_emp_id", "Email/Fax", "Y", "", "1234", ""} indicates that the agent 

is not ready to accept Email/Fax type of work, and 

{"agent_emp_id", "Web Chat", "N", "", "1234", "Y"} indicates that the 

agent is ready to accept web chat type work and he or she is currently working on a web 

chat session. 

15 Referring to table MEDIA_STAT (Fig. 2d), the parameter 

"MEDIA_OBJECT_STR" for phone is the agent's extension number. For email, it is the 
mailbox name or the sender's email address. For fax, it is the fax number. The form of 
the content of MEDIA_OB JECT_STR is defined in each of the channel drivers 120. 

"WORKING_SINCE_DT" is the time the agent starts to talk on the phone, or the 
20 time the agent starts to work on a work item such as an email or fax. 

"WORK_ITEM_STR" is the unique string to identify the work item and the 
value of the field is determined by communication server 109. The MEDIA_STAT table 
is updated at run time to reflect the agent's current work status. An example of an 
agent's data records at run time is as follows: 
25 {"agent_id", "Phone Control", "Ext. 5216", "6/25/2000 12:34:45", 

"phone_item_str", "1 -1S2-X7E" } , 

{"agent_id", "Email", "info@company.com", "6/25/2000 11:34:00", 
"emai l_i tem_str", "1-1 S2-X7D" } 
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The above records show that the agent is currently talking on extension 5216 and 
is working on an email sent to info@company.com. 

Multiple extensions and multiple queues are supported in client/server system 
100 (Fig. 1A) using tables TELESET, EXTENSION, and AGENT_QUE, Figs. 2h, 2i, 
5 and 2j, respectively. The following terms are referenced in Figs. 2h, 2i, and 2j. The 
term automatic call distribution (ACD) extension refers to a type of extension that is 
used to log in to an ACD queue associated with an ACD switch such as ACD switch 
130E . Once an extension logs in to the ACD queue, the ACD switch begins to dispatch 
customer calls to the extension. One ACD extension can log in to one or more ACD 
10 queues. 

The term standard extension refers to a type of telephone extension that is not 
allowed to log in to the ACD queue. Standard extensions are mainly used for dialing 
outbound calls or answering internal calls. The ACD switch does not dispatch customer 
calls to a standard extension. 

15 The term agent ID refers to an identifier used by client/server system 100 to 

identify the agent. In order for client/server system 100 to be aware of the agent's 
availability, each customer support center agent is assigned an agent ID. When the agent 
logs in to a communication channel having an ACD switch 130E, the agent LD is 
provided to the ACD switch 130E. Depending upon the configuration of the system, 

20 either the ACD switch 130E or UQ system 102 determines an available agent ID for the 
work item. Then either the ACD switch 130E dispatches the customer call to the ACD 
extension of the agent ID or, when UQ system 102 is used to assign agents, 
communication server 109 uses one of channel drivers 120 to dispatch the customer call 
to the ACD extension of the agent ID. 

25 "Multiple DN" refers to multiple extensions configured for one telephone 

handset, and one or more extensions are ACD extensions. 

"Multiple queue" means that one ACD extension can log in to multiple queues. 
In general, since an ACD queue is a list of agent IDs, as long as the agent ID is 
acceptable for ACD queue, any ACD extension can be used to login to ACD queue. 
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In one embodiment, a method for determining the list of extensions for an agent 
includes searching by the agent's ID in the AGENT table (Fig. 2j) to find the primary 
Teleset ID in the ACTIVE_TELESET_ID parameter, which identifies the primary 
handset used by the agent. The extension list is then determined from the DN_EXT 
parameter in the EXTENSION table (Fig. 2i). Once the list of extensions is found, all 
extensions that the agent uses can login to all ACD queues defined in the AGENT_QUE 
tables (Fig. 21) for that particular agent. 

As described above, customer support centers can establish configurations that 
define the groups of agents that have similar requirements to communicate, therefore 
requiring access to the same communication channel 130. Configuration base 202 
includes tables about configurations. CFG table (Fig. 2n) contains information about 
configurations. Configuration data includes a configuration name and an INGRP_FLAG 
indicating whether this configuration is for inbound response groups used in inbound 
communication receiver 170. CFG_PROF table (Fig. 2o) is the configuration / channel 
driver profile relationship table showing which channel driver profiles belong to each 
configuration. Each configuration has a single channel driver profile. 

AGENT_CFG table (Fig. 2p) is the agent / configuration relationship table 
showing which agents belong to each configuration. 

CFG_PARM table (Fig. 2q) is the configuration parameter table. A name and a 
value are provided for each configuration parameter. An ACTIVE_FLG field is a flag 
indicating whether the value of the configuration parameter is active. 

The command and event data structure 204, includes information describing 
commands and events implemented by channel drivers 120. This information includes 
associating each command with a channel driver 120 and each event with a channel 
driver 120. 

CMD table (Fig. 2r) includes commands for each channel driver 120. As 
described above, a vendor providing a channel driver 120 specifies the commands that it 
supports. A command is issued to a communication channel j^Q driver 120 by 
communications server 109 to perform a function related to communicati -THg command 
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using communication channel 130. Every click on a button of toolbar 105 invokes a 
command, which is issued to channel driver 120. 

A command can have a group of associated commands which operate as 
subcommands. A group command includes other commands with a Subcommand 
keyword. 

Following is an example of a single command for making a telephone call to a 
contact. 



[Command: MakeCalltoContactl Command definition 

CmdData = "MakeCalltoContact" Command parameter 

DeviceCommand = "MakeCall" Command parameter 

Description = "Make Call to Contact" Command param. 

Hidden = TRUE Command parameter 

[CmdData: MakeCalltoContact] Command data def. 

BusComp = "Contact" Command parameter 

RequiredField.' Work Phone #' _«?*» Command parameter 
Param.PhoneNumber = "{Work Phone # : Lookup} 

Command 
Parameter 

Following is an example of a group command for making a telephone call to a 
contact: 

[Command: MakeCallGroup] 

Hidden = TRUE 

Subcommand = MakeCalltoPhone 

Subcommand = MakeCalltoSRContact 

Subcommand = MakeCalltoSROwner 

Subcommand = MakeCalltoEmployee Home 



The following example command can be either a single command or a 
subcommand 

[Command: MakeCalltoPhone] Command definition 

CmdData = "MakeCalltoPhone" Command parameter 

DeviceCommand = "MakeCall" Command parameter 

Description = "Make Call to { @Phone}" Cmd param 

Hidden = TRUE Command parameter 

[CmdData: MakeCalltoPhone] Command data def. 
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[CmdData: MakeCalltoPhone] Command data def. 

RequiredField.'Work Phone #' ="?*" 
Param.PhoneNumber = "{@Phone: 

PhoneTypeLookup } 

5 A command can have a command data section with a CmdData keyword to 

specify the data parameter in order to communicate with channel driver 120. 

When a customer support center configuration includes multiple channel drivers 
120, it is then possible for communication server 109 to determine which commands and 
events are handled by each of channel drivers 120. This configuration can also help 
10 distinguish between channel drivers 120 from different vendors that use the same name 
for commands performing different functions. 

Following is an example of a command with a data section having a CmdData 
keyword 

[Command: MakeCalltoContact] 

15 CmdData = "MakeCalltoContact" 

DeviceCommand = "MakeCall" 
Description = "Make Call to Contact" 

Hidden = TRUE 

[CmdData: MakeCalltoContact] 
20 BusComp = "Contact" 

RequiredField.'Work Phone #' ="?*" 
Param.PhoneNumber = "{Work Phone # : Lookup} 

The event table contains events that are sent to communication server 109 from 
25 channel driver 120. Vendors specify the events that will be sent in channel driver 120. 
An event response determines how communication server 109 reacts upon receiving 
each media event. The process of handling an event includes the following: searching for 
the event handler for the event, querying a customer support center database to determine 
the appropriate event response, and logging the event. 

30 

As an An example of an event, the event handler, event response, and event log 
for an InboundCall event are shown below: 

[EventHandlenOnlnboundCall] first stage, EventHandler definition 



747719 vl 



17 



Ser. No. 09/823,828 



DeviceEvent = "EventRinging" media event definition 

Response = "OnlnsideCallReceived" EventResponse declaration 

Filter.Call = "?*" EventHandler parameter 

Order = " 1 " EventHandler order 

5 

[EventResponserOnlnboundCallReceived] second stage, EventResponse 

definition 

QueryBusObj = "Contact" EventResponse parameter 

QueryBusComp = "Contact" 
10 QuerySpec = " Work Phone # ='{ ANI } ** 

Single View = "Service Contact Detail View" 

MultiView = "Contact List View" 

FindDialog = "Service Request" 

FindField.CSN = "Ask Caller" 
15 FindLog = "LoglncomingCallContactNotFound" EventLog declaration 

SingleLog = "LoglncomingCallContactFound" EventLog declaration 

Log = "LoglncomingCallContactNotFound" EventLog declaration 

[EventLog:LogIncomingCallContactFound] B EventLog definition 

20 Display = "TRUE" 6 EventLog parameters 

BusObj = "Action" 

BusComp = "Action" 

LogField.Type = "Call - Inbound" 

LogField. ' Account Id' = " { Contact. ' Account Id' } " 
25 LogField.'Contact Id' = "{Contact. Id}" 

LogField.Description = "Inbound call" 

LogField.'Call Id' = "{ConnID}" 

AfterCall.'ACD Call Duration^ "{ ©CallDuration}" 

Each event handler corresponds to an event provided by channel driver 120 and it 
30 is sequenced among the event handlers for an event. Each event handler has an event 
response. An event response can be shared among event handlers. An event response 
can have multiple event logs, and an event log can be shared among event responses. 

When operating in session mode, communication server 109 is under the control 
of session mode communication server 110. Session mode communication server 1 10 

35 receives incoming events such as customer support requests and communicates in real 
time interacti vel y with the agent by controlling a user interface presented to the agent. 
The term real time is used herein to indicate tha t Preferablv the incoming customer 
support request is communicated to the agent at substantially the same time the customer 
support request is received by the communication channels 130. with brief intermissions 

40 only to allow for processing and transport time in transporting the customer support 

request. The term toolbar 105 as us e d herein includes This ensures that the us e r interface 
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within which tho communication toolbar 105 (Fig. lA) customer ? s waiting time is 
pr e sented minimized. particularly for requests for live interacti on with an agent . 

When an event such as arrival of an incoming telephone call occurs, the user 
interface notifies the agent using a notification function to change the user interface to 
5 capture the agent's attention. For example, a notification function can cause a button to 
blink to notify the agent of the phone call. A notification function can also display other 
information such as information about the caller before the agent picks up the phone. 
When the agent uses toolbar 105 to accept a telephone call, put a call on hold, or release 
a call, the user interface sends a command to session mode communication server 110, 
10 which communicates with one of channel drivers 120 to issue the command to the 
communication channel controlling the telephone. 

Session mode communication server 110 also handles establishing and 
maintaining connections to one or more communication channels 130, such as 
communication channels 130A through 130D. Session mode communication server 110 

15 uses one of channel drivers 120, such as channel driver 120A, to establish the 

connection. Having a connection to a communication channel enables the agent to 
receive an incoming work item, such as an email, intended specifically for that agent in 
real time. The connection can be to a middleware server, to a web server, directly to a 
media device, or to any other communication intermediary from which the customer can 

20 receive a communication. The connection can be established as a TCP/IP socket 
connection to a middleware server, as an OLE interface such as the IadviseSink 
interface, or as any other suitable inter-process communication scheme. Each of channel 
drivers 120 contains all information needed to establish the connection with 
communication channel 130 so that communication server 109 operates independently of 

25 communication channel 130. 

Fig. IB shows a detailed view of one embodiment of session mode 
communication server 110. Session mode communication server 110 maintains 
knowledge of clients 104 to which it is connected with each communications channel 
4^Qr . here web browser client 104A. When a request communication from 
30 communication channel 130 such as ACD switch 130E is received, communication 
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server 109 dispatches the request to the appropriate server component in client/server 
system 100 for execution. 

Session thread 122 represents a session during which an agent interacts with 
client/server system 100 using aweb browser client such as on e of web browser client 
5 104A . Session thread 122 represents a connection betw e en web browser client 104 A and 
a telephon e communication channel 120D having a communication channel 130E 
comprising an ACD switch . A customer uses a customer communication device, here a 
telephone, to access the communication channel. The agent also uses a communication 
device, such as a telephone headset, to access the communication channel. 

10 Each session Session threa d 122 listens for inputs from its associat e d web browser 

clien t 104 A and dispatches notifications of events from communication chann e l 
4-3 0 ACD switch driver 120D to ffcs web associate d browser client 104 A . Each 
session Session thread 122 uses a communication channel manager such as 
communication channel manager 124 to interact with e ach of channel drivers 120. ACD 

15 switch driver 120D. Each ef-channel drivers driver 120 provides an active connection 
such as active connection 133 between the client and the associated communication 
channel. Channel driver 120 can provid e an active be implemented to establish a 
persistent connection for interactive communication between the-client 104 and the 
associated communication channels 130E but providing such an active a persistent 

20 connection is not required v bv communication API 125. 

The following examples describe processes that are followed by web browser 
client 104 A 7 during startup, initialization and operation. The processes for web browser 
client 104A are applicable to other types of clients, as will be explained in further detail 
below. 

25 When web browser client 104A begins execution: 

1. Web browser client 104 A downloads program instructions for generating a 
user interface on the display for the web browser, such as Java applet 116 for a 
communication toolbar 105, shown here as implemented using Java applet 116, from 
web server 188. Java applet 116 also establishes an active persi stent HTTP connection 
30 131 between Java applet 116 and web server 188 so that web server 188 can 
continuously provide information to web browser client 104 A. 
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2. Web browser client 104A interfaces with session mode communication server 
1 10 via web engine session thread 166. Object manager 107 spawns web engine session 
thread 166 to interface with web browser client 104A via w e b server 188 using web 
engine plug-in 185 and web eng ine 1 15. Communication client service 160 is loaded to 
provide provides all communication related to the user interface with web browser client 
1 04 A and w e b engine service 115.^ 

3. Communication client service 160 requests the object manager 107 for 
communication service. Communication service 113, which provides all 
communications not related to the user interface, is load e d provided . 

4. Communication service 113 loads configuration information such as 
commands, events, agent information and preferences, channel driver information and 
channel driver parameters. 

5. Communication service 113 registers an asynchronous event receiving 
function with object manager 107 to be invoked when an asynchronous event is 
subsequently received. The asynchronous event receiving function is also referred to as 
a callback function. Receiving asynchronous events is described in further detail below. 

6. Communication service 113 request an active connection 135A between 
object manager 107 and web engine plug-in 185. An 185 and an active connection 135B 
between communication service 1 13 is also established. These and session mode 
communication server 440 110. Persistent HTTP connection 131. and communication 
serv i ce 113 i s also established. These active connections 131, 135A T and 135B enable 
session mode communication server 110 to continually push user interface changes to 
toolbar 105 using Java applet 116. 

7. Session mode communication server 1 10 spawns a session thread such as 
session thread 122 in response to the connection request. 

8. Th e s e ssion Session thread 122 runs communication channel manager 124. 

9. Communication channel manager 124 loads telephone ACD chann e l switch 
driver 120D and passes the channel driver parameters determined by communication 
service 113. 
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10. ACD switch driver 120D establishes an active connection 133 to the ACD 
switch 130E. An alt e rnativ e may not us e an active connection channel driver 
implem e ntation. A vendor implementing channel driver 120 mav choose to provide a 
persistent connection to the communication channel 130. as for telephone connections 
such as active connection 133. However, a persistent connection is not required by 
communication API 125. 

When the agent performs an activity using web browser client 104A that requires 
a command to be executed, such as clicking a button on toolbar 105: 

1. Communication client service 160 searches the command configuration data 
previously loaded for the command to invoke. It also collects the data associated with 
that command and then passes the command and data to communication service 113. 

2. Communication service 113 passes the command and data to communication 
channel manager 124. 

3. Communication channel manager 124 then determines which of channel 
drivers 120 performs the command requested by the client, and passes the command and 
data to the channel driver I20_ such as telephon e ACD channel switch driver 120D for 
execution. 

4. Th eACD channel switch drive r 120D issues the command to the 
communication channe l 130. In this example, the ACD switch driver 120D issues the 
command to ACD switch 130E. 

When a channel driver 120 such as telephone ACD channel switch driver 120D 
needs to push an event (status data or an incoming event such as a customer call) to web 
browser client 104A: 

1. ACD switch driver 120D receives the event and posts the event to 
communication channel manager 124. This requires asynchronous interruption at 
session thread 122 for event posting. 

2. Communication channel manager 124 pushes the event to communication 
service 113. 
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3. Communication service 113 receives the event and executes the registered 
asynchronous event receiving function. 



4. The registered asynchronous event receiving function inserts the event sent 
from telephone ACD channel switch driver 120D into an event queue stored inside object 

5 manager 107. 

5. A frame manager (not shown) running in session thread 122 picks up the 
event from the event queue and invokes the registered asynchronous event receiving 
function using communication client service 160. 

6. Communication client service 160 asks communication service 113 to process 
10 the event. 

7. After communication service 113 has processed the event, communication 
client service 160 continues to communicate with Java applet 1 16 to control the web 
browser for user interface changes. 

Fig. 1C shows components included in one embodiment of request mode 
15 communication server 140. Request mode communication server 140 handles the 

distribution of information via communication channels according to the request. An 
example of the operation of request mode communication server 140 is session mode 
communication server 110 sending a request to request mode communication server 140 
to send a large number of emails on its behalf. This enables session mode 
20 communication server 1 10 to devote its resources to controlling the user interface, 
issuing commands, and handling events. 

A request mode server thread such as server thread 142 is spawned when request 
mode communication server 140 begins execution. Communication manager 152 is 
loaded to collect data for the request. Request mode communication server 140 
25 determines the appropriate channel driver to handle the request and directs a 

communication channel manager 156 to load email driver 120E. Communication 
channel manager 156 dispatches the request and data to email driver 120E, which sends 
the information to email communication channel 130F. In the embodiment shown in 
Fig. 1C, email driver 120E sends the emails via email server 132 to email client 134. 
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As another example of the operation of request mode communication server 140, 
object manager 107 can send one or more work items from UQ system 102 to request 
mode communication server 140. Similar to the previous example, a request mode 
server thread is spawned and communication manager 152 is loaded to collect data for 
5 the request. Request mode communication server 140 determines the appropriate 

channel driver to handle the request and directs a communication channel manager 156 
to load an appropriate driver, such as email driver 120E. Communication channel 
manager 156 dispatches the request and data to the driver, which sends the information 
to a communication channel. 

10 Fig. ID shows an example of one implementation of inbound communication 

receiver 170. One embodiment of inbound communication receiver 170 is designed to 
serve inbound customer support requests with no connection to or knowledge of a client. 
This contrasts with session mode communication server 110, which communicates with 
a client to provide a user interface to at least one agent. In one implementation, inbound 

15 communication receiver 170 handles customer support requests that can be held in a 
queue for future processing, such as fax and email, whereas session mode 
communication server 110 handles high priority support requests that should be 
processed as quickly as possible, such as telephone calls, to improve customer response 
time. In another implementation, both inbound communication receiver 170 and session 

20 mode communication server 1 10 can handle high priority support requests. 

Inbound communication receiver 170 uses channel drivers 120 such as email/fax 
channel driver 120F to "listen" for particular types of customer support requests from a 
common source. Email channel driver 120F handles all email messages directed to a 
particular email address and all faxes sent to a particular fax number. To avoid overlap 
25 among agents, inbound communication receiver 170 can be configured to work with UQ 
system 102 to assign an agent to the inbound customer support request (email 173 or fax 
175) and route the customer support request to a component associated with or 
representing the assigned agent, such as a client. 

Inbound communication receiver 170 is also configured during initialization to 
30 recognize events, such as receiving a customer support request, and to include 

corresponding channel driver information and background profiles to handle recognized 
events. Background profiles include one or more monitored media objects, such as a list 
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of email addresses, fax numbers, and web-chat end points. For example, email 
communication channel 130G represents a background profile for info@company.com 
and fax communication channel 130H represents a background profile for fax number 1- 
800-123-4567. 

5 Inbound communication receiver 170 spawns a server thread such as server 

thread 174 to handle inbound events, such as customer support requests. This contrasts 
to session mode communication server 110, which spawns a session thread such as 
session thread 122 for each client 104 being used by an agent. Communication channel 
manager 177 then initializes a service such as fax service object 183 A, email service 
10 object 183B, or phone service object 183C with the designated background profile. 

When the email/fax channel driver 120F receives an incoming customer support 
request, e.g. new fax 175, fax channel driver 120F posts the event to communication 
channel manager 177. This posting interrupts the idle state of server thread 174 and 
causes server thread 174 to invoke communication channel manager 177 to process the 

15 event. Communication channel manager 177 determines how to respond to the event 

based on an event response sp e cified included in thean event configuration response table, 
such as EVTRESP fFig. 2y\ and invokes the appropriate media service, such as fax 
service object 183 A. If the event response also specifies notifying UQ system 102 of the 
event, the event is then passed to UQ system 102 via UQ business service 106. A 

20 response to the event notification is returned to inbound communication receiver 170 via 
UQ business service 106. 

In alternative embodiments, client/server system 100 can support multiple types 
of clients 104 having hardware/software configurations that are different from web 
browser client 104A. Fig. IE shows an alternative embodiment of client/server system 
25 100 that supports web browser client 104A, thin client 104B, and dedicated client 104C. 

Thin client 104B includes one or more client software modules that are installed 
and executed on the client computer system used by the agent. Thin client 104B 
provides minimal functionality, with the majority of the functions for thin client 104B 
are performed by application server 126. It is often desirable to use thin clients so that 
30 application programs can be updated once in a centralized location instead of multiple 
times for each thin client 104B. 
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Thin client 104B provides more functionality on the client side than web browser 
client 104A, and can, for example, perform some functions of object manager 107. Thin 
client 104B also controls the user interface vi aincluding toolbar 105. If changes are 
necessary to the functions performed on the client side, a new copy of thin client 104B 
must be installed on each individual agent's computer system. 

Dedicated client 104C includes software modules that perform a significant 
portion of the functions required to support an agent. Dedicated clients are sometimes 
referred to as "fat clients," in contrast to the "thin client" designation. If changes are 
necessary to the functionality provided by dedicated client 104C, a new copy of the 
dedicated client software modules usually must be installed on the client computer 
system. 

Dedicated client 104C provides even greater functionality than does thin client 
104B, including, for example, all functionality provided by object manager 107, web 
server 188, communication client service 160 (Fig. IB), and communication service 113. 
Because dedicated client 104C assumes all responsibility for the user interface and 
toolbar 105, there is no communication between dedicated client 104c and 
communication server 109, web server 188, web engine plug-in 185 and web engine 115 
(Fig. IB). Dedicated client 104C does include web server 149 that is capable of 
interfacing with UQ system 102, and object manager 151 to communicate with channel 
drivers 130. 

It is important to note that other types of clients having hardware and software 
components that are different from clients 104A, 104B, and 104C can also be integrated 
with client/server system 100. 

Communication API 

Referring now to Figs. 1F-1J, communication API 125 is provided in one 
embodiment of the present invention for channel drivers 120 to communicate with 
communication server 109. Note that communication server 109 is used in the following 
discussion of communication API 125 to represent session mode communication server 
110, request mode communication receiver server 140, or inbound communication 
receiver 170. 
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As shown in Fig. IF, one embodiment of communication API 125 includes three 
types of objects: driver objects 189, service objects 183, and client objects 183. Driver 
objects 189 and service objects 183 are instantiated at the channel driver 120, however 
client objects 179 are instantiated at communication server 109. Communication server 
5 109 interfaces with driver objects 189 and service objects 183, but only service objects 
183 communicate with client objects 179. 

Driver objects 189 maintain the instantiation of service objects 183. Any special 
steps for constructing and destructing service objects 183 can be implemented in driver 
objects 189. Multiple driver objects 189 can be included to manage different types of 
10 media. Also, a single driver object 189 can manage one type of service objects 183 or 
different tvpetypes of service objects 183. For example, a single driver object 189 can 
manage phone, email and fax media. 

As an example of the operation of driver objects 189, when communication 
server 109 is starting up, the channel driver 120 data link library (DLL) is loaded. 

15 Communication server 109 calls CreateISCSDriverInstance() in channel driver 120 to 

ask for the construction of a driver object 189. The channel driver 120 returns the driver 
handle back to communication server 109. The channel driver 120 determines how 
driver objects 189 are created. If driver objects 189 already exist, for example, the 
channel driver 120 could simply pass the handle of an existing driver object 189 instead 

20 of creating a new one. 

S e rvic e obj e cts 183 In one embodiment, service objects 183 are created by driver 
objgcts J 89, service objects 183 can inh e rit some facilities from driver objects 189 
and/or share some resource with !89 and provide functionality in the form of device 
commands to interact with the associated media type. For example, making an outbound 
25 call, or sending an outbound email is implemented at service objects 183. A service 

object 183 is usually associated with a single type of media. For example, there can be 
service objects 183 for phone media and other service objects 183 for email media. 
Communication server 109 interfaces directly with service objects 183 to invoke a 
device command. 



747719 vl 27 Ser. No. 09/823,828 



After communication server 109 obtains the hand l e to a service object 183, 
C ommunication server 109 wil l use t he s er vice handle directly to inter a ct with the 
service object 183. Sinc e service objects 183 are created by driver objects 189, service 
objects 183 can inherit some facilities from driver objects 189 and/or share some 
5 resource with driver objects 189, For example, driver objects 1 89 can maintain the 

physical TCP/IP connection to a middleware server and service objects 183 can share the 
connection with the driver obj e cts 189. Aft e r communication server 109 obtains the 
driver handle, communication server 109 uses a RequestService() function to request a 
service object 183 for the specified media type. The driver returns the handle of the 
10 corresponding service object 183 to communication server 109. Communication server 
109 then uses this handle in an InvokeCommand() function directly to request the 
corresponding service object 183 for executing a particular type of function. 

After comm unicati on server 109 obt ains the handle to a service object 183. 
Communication se rver 10 9 will use the service handle directly to interact with the 
15 service object 183. Smee Service objects 183 can inherit facilities from, and/or share 
resources with, driver object s 189, F or example, driver objects 189 can maintain the 
physical TCP/IP connection to a middleware server and service objects 183 can share the 
connection with the driver o bjects 189. 



Client objects 179 are instantiated and implemented by communication server 
20 109. The handles to client objects 179 are passed to service objects 183. Service 
objects 183 can utilize the client handles and invoke the function to be executed at 
communication server 109. 

Ever vln one embodiment, every service object 183 will have its has a 
corresponding client object 179. Therefore, each client object 179 has knowledge of the 
25 media type that its corresponding service object 183 is using. Since service objects 183 
can each be instantiated for different media from different driver DLLs, this one-to-one 
relationship allows a client object 179 to know the channel driver 4-3Q object 189 and 
service object 183 that initiate the notification when client object 179 rec e iv e receives 
notification from service object 183. 
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Fig. 1G shows an example of an architecture for driver object 189 instantiated by 
channel driver 120. Driver object 189 creates three service objects 183A-1, 183A-2, and 
183A-3 of the same media type, such as email. Each service object 183A-1, 183A-2, 
and 183A-3 has its own dedicated client object 179A-1, 179A-2, and 179A-3, 
5 respectively. 

Fig. 1H shows an alternative architecture for driver object 189 that creates three 
service objects 183 A, 183B, and 183C for different types of media. Each service object 
183A, 183B, and 183C has its own dedicated client object 179A, 179B, and 179C, 
respectively, for processing events with the corresponding media type. An example of 
10 this architecture is shown in Fig. ID for inbound communication receiver 170 that 
includes client object 179A for handling fax media, client object 179B for handling 
email media, and client object 179C for handling phone media. Client objects 179A, 
179B, and 179C correspond to fax service object 183A, email service object 183B, and 
phone service object 183C, respectively. 

15 Fig. II shows two driver objects 189A, 189B instantiated in the channel driver 

120. Each driver object 189 A, 189B is designated for a different middleware server and 
includes resources specific to the type of middleware server. For example, driver 
object 189A may use a TCP/IP connection to Middleware Server A and driver object 
189B may have a direct connection to Middleware Server B. The service objects 183 

20 created under each driver object 189 A, 189B are specific to the middleware server with 
which the driver object 189 A, 189B is associated. 

* 

There are several alternatives for implementing asynchronous notification of 
events from middleware servers to driver objects 189 including: 

1. Traditional TCP/IP socket. The driver objects 189 connect to the TCP/IP port 
25 of a middleware server. Events are sent through TCP/IP connection. 

2. OLE interface. One example is the IAdviseSink interface in OLE. 

3. Any other inter-process communication scheme. 

With alternative 1, since the driver objects 189 are can be implemented as a DLL, 
the driver object DLL either constructs a listening thread which blocks on select() call 
30 until the arrival of event, or a polling thread which periodically polls the middleware 
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server for the arrival of event. Polling threads are useful for low-priority media 
type types , e.g. email or fax, because polling periods typically last seconds or minutes. 
Polling threads are not as useful to detect high-priority media events, such as phone 
requests, because it is desirable to report the arrival of incoming call at anytime. 
5 Listening threads generate less network traffic than polling threads, and are generally 
useful for high priority and low priority media, however, some types of middleware 
servers do not support listening threads. 

To implement both polling threads and listening threads, a "task" thread is 
required in the driver object DLL. The "task" thread can be executed in driver objects 
10 189 as shown in Fig. 1J or in service objects 183 as shown in Fig. IK. 

Referring to Fig. 1 J, a task thread (or listen thread) implemented in the driver 
objects 189 may be "shared" by all service objects 183. For example, this listen thread 
can listen for all incoming events for all service objects 183. Once the listen thread 
receives an event, the listen thread then invokes and executes the event handling function 
15 implemented at service objects 183. 

Referring to Fig. IK, if the listen thread is implemented at the domain of service 
objects 183, every service object 183 constructs its own listen thread and the listen 
thread is not shared. Each listen thread £is] listens to a different target. For example, 
listen thread for user 1 listens for events on the first phone extension (ext. 1234), while 
20 the listen thread for user ±2 listens for events on the second phone extension (ext. 5678). 

Gteett tln one embodiment, client objects 179 are a collection of function pointers 
implemented by Communication c ommunication server 109 and passed to the service 
objects 183 for asynchronous event notification. In one implementation, when the listen 
thread in channel driver 120 receives an event, the following processes occur: 
25 1. Service object 183 eatis invokes the HandleEventO . HandleEvent function 

implemented in corresponding client object 179 is e xecuted. 179. 

2. Client object 179 queues this event to a memory cache. 

3. Client object 179 interrupts or signals the server thread 174 (Fig. ID) for 
Communication channel manager 177 to indicate the arrival of an event. Once 

30 this process is completed, the listen thread waits for the next event. 



747719 vl 



Ser. No. 09/823,828 



4. During the next cycle of server thread 174, main thread sees an event is 
available in the memory cache. It dequeues the event out of the memory 
cache and continues the processing. 

Communication API Commands 



5 Communication API 125 includes commands and data structures to allow third 

parties to develop applications that can integrate with client/server system 100. The data 
structures include arrays for passing data elements such as an agent's key value element, 
key value parameters, and string parameter lists. 

The following provide examples of runtime status flags that can be used in 

10 communication API 125: 

NOTSUPPORTED =1; Command is not supported 

DISABLED = 2; Command is disabled at this time 

CHECKED = 4; Command is in "checked" state, for example when 

agent is in busy mode the "busy" command will be 
15 "checked" 

BLINKING = 8; This is special effect flag to enable the blinking 

"answer call" command 
NOPARAMSOK =16; Command does not require any parameters to execute 
STRPARAMSOK = 32; Command can be executed by providing single 
20 unnamed string parameters. Such commands are 

invoked when the agent types something in the edit 

control of the communication toolbar 105 and clicks 

the corresponding button. 

The following provide examples of commands that can be used in one 
25 embodiment of communication API 125: 

MediaType: The MediaType command is used from channel driver 120 to 

provide the media type. ¥h eAn indicator ofthe media- type-stfm ^_such 
as the following examples of media type strings, is passed to the channel 
driver 120 at the CreatelSCDriverlnstanceOr Junc tion: 

30 PHONECONTROL = 1 

CALLROUTING = 2 

EMAIL = 3 

FAX =4 

WEBCALL = 5 

35 WEBCHAT = 6 
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CommandTvpeEx: Channel driver 120 uses the CommandTypeEx function to 
request different services, such as making calls and sending messages, 
from communication server 109. 



ObiectTvpe: T he SCObiectvpe ObiectTvpe function is used to monitor the 
5 communication objects, which can be represented by the following 

parameter values: 



OB_LINK = 1 

SWITCH = 2 

QUEUE =3 

10 TELES ET =4 

DN =5 

AGENT = 6 

CALL = 7 

CALLROUT = 8 

15 EMAIL = 9 

FAX = 10 

WEBCALL =11 

WEBCHAT = 12 

OTHERS = 1000 



20 ObjectPropertv: The function ObjectProperty can be used to provide properties 

of monitored communication objects, such as: 

©P=ONOFF = 1 

©P-^AGENTED = 2 
©fySTOTRE AD Y = 4 
25 ©PziBUSY = 5 

©^DESCRIPTION = 7 
©PzzTIMEINQUEUE =9 
©PzzQUEUEID = 12 
©JMSLOGON = 13 

30 



Channel Driver Functions 



In one embodiment, a-driver objects 189 within each of channel drivers 120 can 
include the following functions: 

FreeSCStrParamList is invoked by communications server 109 to release the 
35 memory which is initially allocated by channel drivers 120. 
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RequestMediaTypeList is invoked by communications server 109 to query the 

list of media type strings supported by channel drivers 120. It can include 
the parameter mediaTypeList, which is a list of media-type strings. 

RequestCommandEv e ntList is invoked by communciations server 109 to query 
5 the list of d e vice commands and d e vice events supported by the channel 

drivers 120. 



FreeSCStrParamListO is invoked by communication server 109 to release 
memory. 

10 RequestCommandEventList is invoked to generate lists of commands and events 

that are implemented for a particular media type^ supported bv the 
channel drivers 120. The parameters can include an input parameter 
specifying the media type, and output parameters that include lists of the 
commands and events. 

15 CreatelSCDriverlnstance is invoked to create a channel driver 120. The 

following parameters can be used: 

mediaTypeStr: the media-string that is defined by a particular driver 
implemen tati on . 

languageCode: the language string, e.g. "ENU" for English, "FRA" for 
20 French, "DEU" for German, "PTB" for Portuguese-Brazilian, 

"ESN" for Spanish, "ITA" for Italian, and "JPN" for Japanese. 
connectString: the connect string for the channel driver 120 
datasetParams: the parameter list collected from the configuration 
handle: the handle to channel driver 120 returned by the channel driver 
25 120 

RequestService requests media functions service object 183 from the channel 
driver 120. The following parameters can be used: 
clntlnterf ace: the interface at the client sk teobject 179 
connectString: the connect string for the service objects obiect 183 
30 datasetParams: the parameter list collected based on the configuration 

serviceHandle: the handle to the service objects object 183 returned by 
the drive r 120 

ReleaselSCDriverlnstance is invoked by communication server 109 to release the 
driver instanc e obiect 189 specified by the driver handle supplied as a 
35 parameter. 
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Service Object Functions 

In one embodiment, service objects 183 within each of channel drivers 120 can 
include the following functions: 

s 

ReleaselSCServicelnstance is invoked to release the service object's handle. 

5 NotifyEventHandlingFinished is invoked by communications server 109 to notify 

the chann e l driver -jrSQ obiect 189 that the event handling is complete and 
the channel driver -l^Q obiect 189 can move on or continue the process. 
This function is invoked to respond to HandleEvent's notify WhenDone 
parameter. The following parameter list parameters can be used: 
10 Handle: identifier of the service object JJ^L 

trackingID: an identifier for the work item for which the communications 

server 109 was doing event handling, 
result: the result of event handling query of the list of media type strings 

supported by the channel driver 120. 

15 InvokeCommand is invoked by communications server 109 to invoke a driver 

command. The following parameter list can be used: 
Handle: identifier of the service object 

clntCmdTracklD: the unique ID for the InvokeCommand request 
name: the command name to invoke 
20 stringParam: the string from "Phone #" edit box on the toolbar 105 

datasetParam: the parameter list collected based on the configuration 

InvokeCommandEx is invoked by communications server 109 to invoke a certain 
type of command. The following parameter list can be used: 
Handle: identifier of the service object, 

clntCmdTracklD : the unique ID decided by the communications server 

109 for this InvokeCommand request^ 
commandType : the type of command the communications server 109 
wants to execute^ 

datasetParam : the predefined parameter list set by the communications 
serve r 109. 

ReleaseWorkltem is invoked by communication server 109 to request release of a 
work item. Parameters can include: 
Handle: identifier of the service object^ 
TrackingID: identifier of the work item. 

35 SuspendWorkltem is invoked by communication server 109 to request the service 

object 183 to suspend a work item. Parameters can include: 
Handle: identifier of the service objec t 183. 
TrackingID: identifier of the work item. 

ResumeWorkltem is invoked by communication server 109 to request the service 
40 object 183 to resume a work item. Parameters can include: 



25 



30 
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Handle: identifier of the service object 183. 
TrackingID: identifier of the work item. 



HandleQueuedEvent is invoked by communication server 109 to pass an event 
previously queued in UQ system 102 to the service object 183 for 
5 handling. The channel driver 120 can treat this as an incoming media 

event from the middleware server. Parameters can include: 
Handle: identifier of the service object, 

name : the event name (from the original HandleEvent() cal\\ 
fields : the event attributes list (from the original HandleEvent() call)^ 
10 trackingID : the unique ID for the media itenru 

CancelQueuedEvent is invoked by communication server 109 to notify the 

channel driver 120 that a media-event is cancelled, released, or transferred 
by UQ system 102. This function is the companion function of 
HandleQueuedEvent(). The following parameters can be used: 
15 Handle: identifier of the service object, 

name : the event name (from the original HandleEvent() call^ 
trackingID : the unique ID for the media item £ 

Client Object Functions 

The following are examples of functions that can be included in Client Objects 
20 179. The interface to these functions can be implemented with a function pointer so that 
driver objects 189 do not need to link to any libraries in communication server 109. 

RoquostSorvicoO issu es a request from client objects 179 to driver objects 189. 
The CLIENT_INTERFACE object and the CLIENTJHANDLE are passed as 
parameters. 

25 ReleaseClientlnstance causes driver object 189 to release a client object's handle. 

BeginBatch and Endbatch are designed to savin g saye network overhead. The 

ISC CLIENT INTERFACE function calls client object functions called 

between BeginBatch and EndBatch wiH can be cached and sent out at thg 

EndBatch call. These two functions can be used at the discretion of the 

30 driver object 189. This is the For example usag e, 

BeginB atchJHelper (c 1 i en tlnterf ace) ; 

CacheCommandInformation_Helper(clientInterface, ...); <-- cached 
; ; ; ; // some processing 
if (error) 

35 HandleError_Helper(clientInterface, ...); <— cached 

HandleEvent_Helper(cIientInterface, ...); <— cached 



747719 vl 



35 



Ser. No. 09/823,828 



EndBatch__Helper(clientInterface); <— All requests will be sent out in 
one request 

*/ 

HandleEvent is used to handle the named event received from the channel driven 
5 120. using the given fields. By calling this method, the channel driver 

120 notifies the client objects 179 of the event, such as a call coming in 
on the monitored teleset. The following is the parameter list: 
Handle: identifier of the service objec t 183. 
name : the event name, 
10 fields : event attributes list, 

notify WhenDone : When set to TRUE, Gliefttelknl objects 179 will 

tes einvoke notifyEventHandlingFinished() to notify the drive r 120 
as soon as the event handling is done. 
trackingID : the ID uniquely identifies the work item that this event is 
15 associated with, e.g. call ID, email ID or web-chat 

session ID. Th e length of trackingID should not e xc e ed 
MAX„TRACKING_1D„LEN. 

ShowStatusText displays textual status information in the status line of the client 
objects 179. The following is-fche-parameter list can be used : 
20 Handle: identifier of the service objec t 183. 

text : the text to display at the client status bar, 

HandleError handles asynchronous errors and logs them to an error log file. The 
following parameters can be used: 
Handle: identifier of the service objec t 183. 
25 clntCmdTracklD : if not 0, it is the same "clntCmdTracklD" 

value passed toInvokoCommand to InvokeCommand Q to 
reflect the error caused by the request in 
InvokeCommand(). If it is 0, the error occurs out of 
context. 

30 error : the error text. 
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CacheCommandlnformation is used to notify the client objects 179 about 
command status caching. The following parameters can be used: 
commandNames: list of command names^ 

commandDescriptions: list of description text for each command, 
5 commands tatuses: list of status ( SCCommandHa g CommandFlag ) for 

each command £ 

UpdateObjectlnformation is used to notify the client objects 179 about status 
change of objects. The following parameters can be used: 
trackingID : the ID uniquely identify the call that causes this information 
10 update^ 

objectType : enum of SCObjoctType enumerated ObjectType value. 
objectID : the unique ID for this object. For phone, it is the extension. 

For email, it is the mailbox. For fax, it is the fax number, 
datasetlnfo : the list of SCObiectPropert y ObiectPropertv ^^akt evalues to 
15 update. For example, thgJkL{ {"4", "TRUE"}, {"72", "33"} } 

rSC OP indicates ISNOTREADY is TRUE and 
SC_OP_TIMEINQUEUE is 33 seconds ) where the first key of "3" 
is SC_OP_ISTALKING and th e value is "TRUE" . The second 
key of "6" is SC_OP_TALKINGSINCE and the value if 
20 "03/12...." 



IndicateNewWorkltem notifies client objects 179 about the arrival of new 

inbound work item (e.g. call, email or fax) . The following parameters can 
be us e d: 

25 trackingID : the unique ID to identify this work itemoldTrackinglD : if 

the driver or the middleware supports a facility to change the work 
item's ID. Use this oldTrackingID to identify th e old ID. This is to 
tell client objects 179. "Her e is The following parameters can be 
used: 

30 trackingID -7 -: the unique ID to identify the new work item , but it 

originat e d from a 
oldTrackingID: ID to identify the old work item " ID. 
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WorkltemStarted notifies client objects 179 that the agent has started working on 
one particular work item. This happens when (1) the agent answers a call 
and the call is connected, or (2) the agent accepts aan email/fax work 
item. In response, client objects object 179 set sets the work item 
identified by "trackingID" as the active work item and stert starts tracking 
this work item. The agent will be treated as talking or working. The start 
time of this work item wi Ucan be recorded by client objects 179. The 
following parameters can be used: 

trackingID : the unique ID to identify this work item, 
oldTrackingID : See the comment of the function 

IndicateNewWorkItem(X 
objectType : the object type^ 

objectID : the media object for this work item. For phone, it is the 

extension. For email, it is the mail box. 
description : the description of work item which will be display e d at 

the top o fcombo box . Driver implementation can 

us e UpdateObjectlnformation tochange use 

UpdateObiectlnformation to change the description of work item. 
startTime : the time the work item is started^ 

WorkltemReleased is used to notify client objects 179 that a particular work item 
is released. This happens when (1) the agent releases a call and the call is 
disconnected, or (2) the agent completes an email/fax work item. In 
response, client objects 179 stop tracking this work item and remove this 
work item. The following parameters can be used: 
trackingID : the unique ID to identify the work item that is being 
released. 

stopTime : the time the work item is released/stopped. 

C 1 e an A 1 1 Wo r klten s Cl ean Al 1 Workltems notifies client objects 179 that all work 
items stored in client objects 179 should be removed. 
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WorkltemSuspended notifies client objects 179 that a work item is suspended. 
This happens can happen, for examp le, when (1) the agent puts a call to 
hold, or (2) the agent suspends an email/fax work item. The driver 
implementation calls this function when suspension is done. In response, 
5 client objects 179 save the working context for this particular work item. 

The following parameter can be used: trackingID : the unique ID can be 
used to identify the work item 

WorkltemResumed notifies client objects 179 that a suspended work item is 
resumed. This happens can happen, for example, when (1) the agent 

10 unholds a call and the call is retrieved, or (2) the agent resumes an 

email/fax work item. The driver objects 189 call this function when 
restoring is complete. In response, client objects 179 restore the working 
context(screen + work-tracking obj) and set the active work item as the 
one identified by "trackinglD". The foil o win g parameter 

15 param e ters trackingID can be us e dtrackingID : the unique ID used to 

identify the work item^ 

Note that other functions and parameters can be included in communication API 
125 instead of, or in addition to, the functions listed herein. 

Universal Queuing System 

20 UQ system 102 queues requests for all types of media until an agent is assigned 

to the request. As agents become available, either by an agent logging in, finishing a 
task, or due to a change in state or assignment, UQ system 102 pushes a work item from 
a communication channel to an agent, and removes the work item from the respective 
queue. In one implementation, when multiple work items are routed to an agent, the 

25 work item that arrived first is presented to the agent and the other work item is returned 
to its respective queue and rerouted/pushed to the next available agent that is capable of 
handling the particular work item. 

UQ system 102 includes UQ receiver 302 and UQ requester 304 that interface 
with UQ engine 306 via UQ server 308. A n ent e rprise application integration (EA l) Web 
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server 146 can be included in system 100 to receive messages from UQ system 102. In 
one embodiment, web server 146 receives the message and sends it to EAI object 
manager 190. EAI object manager 190 packages the messages and transmits it to UQ 
business service 106. In other embodiments that do not include EAI object manager 190, 
5 the message can be sent directly to UQ business service 106. 

UQ Business Service 

UQ system 102 interfaces with UQ business service 106 and web server 146 via 
UQ application programming interface (UQ API) 314. UQ business service 106 places 
information received from UQ system 102 into data structures used by communication 
10 server 109. UQ business service 106 also places information from communication 

server 109 into data structures, commands, and parameters recognized and used by UQ 



API 314. 



In one embodiment, UQ business service 106 includes the following functions, 



15 



with input and output parameters shown in parentheses, for initializing and 
communicating with the UQ system 102: 



UQOpenConnection (UQConfigurationName, Return) 



Provides UQ business service 106 with the necessary UQ configuration 
parameters to receive messages from communication server 109. The 



20 



parameter "Return" in all of the UQ business service functions indicates 
status of the function upon return, for example, "0" means execution was 



successful. 



UQAssign (Return) 

Provides the UQ business service 106 with the necessary UQ 
configuration parameters to communicate with the communication server 



25 



109. 



UQInitRules(Return) 

When UQOpenConnection is called, UQ business service 106 determines 
whether to upload rules, such as agent rules, and work item escalation 
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rules. This function is called during the start-up of communication server 
109. If the rules are to be sent, this function retrieves route rules and 
escalation rules from a data table and packages them for transmission to 
UQ system 102. Once rules are downloaded to UQ system 102, the 
UQReplaceRules function is called to modify the rules. 

UQReplaceRules(Return) 

This function is called when the UQ rules need to be updated, such as 
when changes are made to a set of agent or escalation rules while 
communication server 109 is in operation. 

UQ Disconnect (Return) 

Commands UQ system 102 to terminate the connection between UQ 
system 102 and web server 146, and between UQ system 102 and 
communication server 109. This function is called when UQ system 102 
services are no longer needed. 

In one embodiment, UQ business service 106 also includes the following 
functions for initializing and maintaining agents: 

AgentLogon (AgentLogin, Return, AgentState) 

This function allows an agent to log into UQ system 102. Once the login 
is successful, agent is ready to receive work items. The AgentLogin 
parameter is the agent identification number assigned in communication 
server 109. The AgentState parameter is set to a value indicating the 
agent's state after the function is executed. 

AgentLogout (AgentLogin, Return, AgentState) 

This function allows an agent to log out of UQ system 102. Once the 
logout is successful, UQ system 102 will not queue any more work items 
for this agent. 

AgentInitAuxwork(AgentLogin, Output) 
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This function requests UQ system 102 to place the agent in AuxWork 
mode after all the current work items are completed. In AuxWork mode, 
agent will not receive more work but will remain logged in to the UQ 
system 102. 

5 AgentAvailable(AgentLogin, Return, AgentState) 

This function requests UQ system 102 to place the agent into available 
status. In the available state, the agent is ready to receive work items. 

Request AgentMediaMode (AgentLogin, MediaType, Return, AgentMediaMode) 
This function allows clients 104 to request the agent state. 

10 Change AgentMediaMode (AgentLogic,Return, AgentMediaMode) 

This function allows clients 104 to change the media mode for an agent. 

ChangeAgentSkil (AgentLogin,Return) 

This function allows clients 104 to update the skill of an agent. After an 
agent's skill has been changed, this function should then be used to 
15 update UQ system 102 with the new agent skill. 

RequestAgentState (AgentLogin,Return, AgentState) 

To request UQ system 102 to report the current agent state. 

Request AgentWorkltemList (AgentLogin, Return, WorkltemID, MediaType, 
IsScheduledTask, ScheduleStartTime, ScheduleEndTime, AgentID, 
20 WorkltemState, WorkltemDataProperty) 

Request the UQ system 102 to return a list of all work items currently 

being handled by an agent. 

RequestAgentWorkableList (AgentLogin, Return, WorkltemID, MediaType, 
IsScheduledTask, ScheduleStartTime, ScheduleEndTime, AgentID, 
25 WorkltemState, WorkltemDataProperty) 

This function requests UQ system 102 to return a list of possible work 
items for the agent. This function is used when the agent wants to pick a 
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particular work item rather than being assigned to work items by UQ 
system 102. 

RequestWorkltemAssignment (AgentLogin, WorkltemID, Return) 

This function requests UQ system 102 to dispatch the specific work item 
to the agent if possible. If the work item is still available, the Return 
parameter code indicates SUCCESS and the work item will be delivered 
through communication server 109. 

RequestAgentMediaState (AgentLogin, Return, MediaType, AgentState, 
NumWorkltems) 

This function requests UQ system 102 to report the media (channel state) 
for each media that the agent is capable of handling. 

In one embodiment, UQ business service 106 also includes the following 
functions for initializing and maintaining work items: 

AddWorkltem (WorkltemID, MediaType, IsScheduledTask, ScheduleStartTime, 
ScheduleEndTiem, WorkltemDataProperty, Return) 

This function requests UQ system 102 to add the specific work item into 

the UQ system 102 for future dispatch. 

RequestWorkltemState (WorkltemID, Return, WorkltemState) 
This function requests the current state of a work item. 

AcceptWorkltem (WorkltemID, Return) 

This function allows clients 104 to tell UQ system 102 that the assigned 
work item has been accepted. As a result, agent state and work item state 
are updated by UQ system 102 to reflect the acceptance of the work item. 



RejectWorkltem (WorkltemID, AgentLogin, Reason, Return) 
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This function allows clients 104 to tell UQ system 102 that the assigned 
work item has been rejected. As a result, the work item will be sent back 
to the queue and the agent state for the channel will be set to AuxWork. 

Complete Workltem (AgentLogin, WorkltemID, Return) 
5 This function informs UQ system 102 that the work item is completed. 

The next state for the agent will depend on the Auto-Wrap setting, which 
can be set via a user interface such as toolbar 105. If Auto- Wrap is True, 
the agent is in Wrap mode and the work item will be in wrap mode. If 
Auto- Wrap is FALSE, the agent is placed back in the Available state. 

10 HoldWorkltem (AgentLogin, WorkltemID, Return, WorkltemState, 

New AgentS tate). 

This function requests UQ system 102 to put a work item on hold status. 

UnHoldWorkltem (AgentLogin, WorkltemID, Return, WorkltemState, 
NewAgentState). 

15 This function requests UQ system 102 to take a work item off hold status. 

BlindTransferWorkltemToAgent (AgentLogin, WorkltemID, Return) 

This function transfers a work item to another agent. If the agent is not 
available, the work item can be queued for the agent. 

TransferWorkltemToAgent (AgentLogin, WorkltemID, Return) 

This function tells UQ system 102 to transfer the work item to the agent. 
If the agent is not available, UQ system 102 can inform the requesting 
agent that the work item is not deliverable. 

TransferWorkltemToRoute (AgentLogin, RoutelD, Return) 

This function transfers an agent to a route defined in the system 100 (Fig. 
1A). A route represents a specific way to process the work item. 
Transferring a work item to a route redefines the characteristics of the 
work item and the way the work item should be handled. For example, 
the work item was first believed to be best handled by agents with 



20 



25 



30 
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knowledge in one area and now find that it should be handled by an agent 
having knowledge in another area. Therefore, this work item is 
transferred to a route that can handle the work item. 

In one embodiment, UQ business service 106 includes the following functions for 
reporting performance statistics: 

SetChannelStatlnterval (Interval, Return) 

This function is used to set the feeding interval of the channel real time 
statistics. A predetermined default, such as 60 seconds, can be used. 
Statistics are transmitted to UQ business service 106 and logged into a 
table. 

Start AgentStat (Interval, Return) 

This function is used to initiate the transmission of agent statistics. Data is 
logged to an agent statistics table. 

StopAgentStat (AgentLogin,Return) 

This function is used to stop the transmission of agent statistics. 

In one embodiment, UQ business service 106 includes the following functions for 
handling work items: 

HandleWorkltem (AgentLogin, WorkltemID, MediaType, IsScheduleTask, 
ScheduleStartTime, ScheduleEndTime, AgentLogin, WorkltemState, 
DataProperty, MediaType, IsScheduleTask, ScheduleStartTime, 
ScheduleEndTime, AgentLogin, WorkltemState, DataProperty, Return) 

This function is used to inform a client that a work item is being assigned 

to an agent. 

HandleWorkltemStatus (WorkltemID, MediaType, IsScheduleTask, 
ScheduleStartTime, ScheduleEndTime, AgentLogin, WorkltemState, 
DataProperty, Return) 

This function is used to inform clients 104 that the status for the work 
item has been changed, so clients 104 can take any action that is 
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necessary as a result. For example, work item status could be changed 
from alerting to complete because the other party abandoned the work 
item. In this case, clients 104 may have some housekeeping to perform. 



5 Handle AgentStateCh an ge (AgentLogin, AgentState, Return) 

This function is used to inform UQ client that the state of the agent has 
been changed. 

HandleRouteStatisticsRequest (RouteStat, TotalWorkltems, AverageWaitTime, 
10 AverageServeTime, NlongestWaitTiem, OperationMode, Return) 

This function is used to inform clients 104 of the arrival of route statistics 
information. This method will handle the incoming statistics information, 
for example, by writing it to a database. 



15 HandleAgentStatisticsRequest (AgentLogin, TotalWorkltems, 

AverageServeTime, Average WrapTime, TotalAuxTime, TotalServingTime, 
TotalLoginTime, TotalServedWorkltem, Return) 

This function is used to inform the UQ client of the arrival of agent 
statistics information. This method will handle the incoming statistics 
20 information. Very likely the information will be written to a database. 

HandleError (MessageCode, Return) 

This function is used to inform UQ client that an error is received. 



25 HandleAlarm (MessageCode,Return) 

This function is used to inform UQ client that an alarm is received. 

HandleJournal (WorkltemID, WorkltemDataProperty, AgentStateHist, 
AgentLogin, AgentState, StartTime, EndTime, UQReasonCode, 
30 AgentReasonCode, EscHist, SzStep, StartTime, EndTime, UQReasonCode, 

AgentReasonCode, Return) 

Journal of a work item to be sent to UQ client when the work item is 
completed. UQ client will log the journal into database. 
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The foregoing lists are examples of functions that can be included in UQ business 



service 106. Other functions can be included in addition to, or instead of, these 
examples. Some of the functions include return codes and/or state codes to indicate 
whether a requested function was performed successfully and/or the state of UQ system 
5 102, a work item, or an agent. The following lists provide examples of codes that are 
used as parameters in the preceding functions: 
Return Code 





0 


Success 




1 


Success_More_Status 


10 


2 


Error_Uq_Initialized 




3 


Error_Uq_Not_Initialized 




4 


Error_Failed 




5 


Error_System_Wrong_Api 




6 


Error_System_Initialization_Failed 


15 


7 


Error_Agent_Setting_Invalid_State 




8 


Error_Agent_Undefined 




9 


Error Agent Unable To Change Skill 

— o — — — o — 




10 


Error_Queue_Not_Initialized 




11 


Error_Queue_Undefined 


20 


12 


Error_Queue_Capacity_Exceeded 




13 


Error_Workitem_Adding_Failed 




14 


Error_Workitem_Failed_Change_State 




15 


Eiror_Unkno wn_Medi a 


25 


Agent State 






1 


Available 




2 


Logout 




3 


Busy 




4 


AuxWork 


30 


5 


InitAuxWork 




Media Mode 






1 


Available 




2 


Una va i 1 ab 1 e 


35 


3 


Busy 




4 


Wrap_Up 




Operation Reason Code 




1 


Setting_Invalid_State 


40 


2 


Agent_Not_Available 




3 


Route_Undefined 




Work Item State 


45 


1 


Active 




2 


Wrap_Up 




3 


Alerting 
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4 Completed 

5 Queued 

6 Scheduled 

7 On_Hold 

8 Received 



UQ Configuration 

Referring to Figs. 1 A-E and 3, clients 104 choose a UQ configuration via the 
UQOpen Connection function in UQ business service 106. UQ system 102 uses 
information such as "UQ receiver server name" and "UQ receiver Port" to determine 
10 where to send responses. In one embodiment, multiple receiver servers (not shown) in 
EAI object manager 190 can be connected to receive messages from UQ system 102, 
and, therefore, each receiver communicating with UQ system 102 sends a UQ 
configuration parameter in the UQOpenConnection function. 

Table 1 shows an example of parameters in a UQ configuration table that is 
stored in UQ system 102 and used to establish communication with and perform 
functions as requested by communication server 109 via the UQOpenConnection 
function. For example, Table 1 includes parameters for identifying and establishing 
communication with the host for UQ system 102. Table 1 also includes default settings 
for agent preferences such as whether an agent is in the auto-ready state after login or in 
the auto-auxwork state after login. 



Table 1 : UQ Configuration Table 



Configuration Name 




UQ Host Name 


Identifier for host for UQ system 102 


UQ Host Port 


Address of host 


HTTPURLTempl ate 


Name of primary receiver server 


HTTPLoginURLTemplate 




HTTPLogoutURLTemplate 




Business Service 


Specify the name of UQ business service 106 that 
will be invoked when outbound XML is sent. 


Method 


The name of method to be invoked in the UQ 
business service 106 mentioned above. 


MaxConnection 


Maximum number of connections to be opened on 
the primary receiver server. UQ system 102 has the 
option to send events to any of those open 
connections. By opening up multiple connections, 
multiple requests can then be processed. 
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15 



20 



Transport 


Web server 146 and EAI object manager 190 
require: 

Name of server for UQ system 102 
Listening Port for UQ system 102 

Workflow process 144 requires: 
Name of server for UQ system 102 
Listening Port for UQ system 102 
Sender WorkFlow Name 
Send Method Name 


SecondaryHTTPURLTemplate 


For secondary UQ receiver server (optional). If 
included, this receiver server is used for primarily 
for non-time critical message such as alarm, error, 
statistics and journal. If no secondary receiver 
server is included, the primary receiver server in 
EAI object manager 190 can be used. 


SecondaryHTTPLogoutURLTempl 
ate 


Template for logout information 


SecondaryHTTPLoginURLTempla 
te 


Template for login information 


SkillBC:<Business Component 
Name> 


A Skill map that contains a list of skills and 
associated skill items for a client. Includes a list of 
business skills. For example, 

SkillBO:Industry = Industry 
SkillBO:Internal Product = Internal Product 
SkillBO:Language Def=Language Def 
SkillBO:Product Line=Product Line Briefing 


AuxWorkAfterLogin 


If "true", place the agent to Aux mode after login. 
Default is "true" 


LogoutFromAvailable 


If "true", allow agent to logout at Available state. 
Default is "true" 


WrapEnabled 


If "true", wrap state is valid for agent. Default is 
"true" 


Load Balancing 


If "true", Server Load Balancing is used and 
installed. Default is "false" 



Table 2 shows a subset of parameters in the UQ Configuration table in Table 1 
referred to as Propertylnfo parameters that are used in other functions that are included 
in UQ business service 106. 



Table 2: Property Information Parameters 



Name 


Purpose 


UQ Host Name 




UQ Host Port 
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HTTPURLTempl ate 


Template to be used in HTTP URL for login and 
making requests 


HTTPLoginURLTempIate 


Template to be use in HTTP for login 


HTTPLogoutURLTemplate 


String that needs to be included in the logout 
process 


MaxConnecti on s 


Number of connections that need to be opened 


Secondary Receiver Host 




Secondary Receiver Port 




SecondaryHTTPURLTemplate 




SecondaryHTTPLogoutURLTempl 
ate 


String that needs to be included in the logout 
process 



Web server 146 31 4 handles packing information using a suitable data transfer 
protocol for outgoing messages to EAI object manager 190. In one implementation, for 
example, HTTP is used to communicate messages to and from UQ API 314. Web server 
146 converts information in HTTP format to another suitable transport protocol which 
5 EAI object manager 190 unpacks for use by UQ business service 106. In other 

embodiments, other protocols known in the art can be used instead of, or in addition to, 
HTTP. 

UQ Routing 

UQ engine 306 defines a route for processing each work item. For example, if a 
10 work item is a fax requiring response from an agent with knowledge of computer 
networking, the UQ engine 306 would define a route that specifies an agent with 
computer networking skills. An agent can transfer the work item to a route queue using 
the functions TransferWorkItemToRoute(Route configuration Name) or 
BlindTransferWorkltemToAgent(agentlD) if the agent is not able to respond to the work 
15 item. The skill requirements for the work item can be changed before invoking the 

transfer if the agent determines that a different skill is necessary to respond to the work 
item. 

In one embodiment, route points are generated, wherein each route point has 
specific skill requirements. When a work item is to be transferred to another point, the 
20 transferring agent can choose a route point from a pop up list, for example. The list can 
include the option to either list all agents or all route points. 

UQ System Scenarios 
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The following examples show how requests from clients are processed through 
one embodiment of system 100: 

Initialization and Rules Download 

Communication server background mode server 170 uses UQOpenConnection 
5 function in UQ business service 106 to connect clients with UQ system 102. In one 
embodiment, two or more configurations can be available to initialize UQ business 
service 106, including a default configuration. The default UQ configuration parameters 
are used if no other configuration specified. The UQPropertylnfo parameters of 
UQOpenConnection included PrimaryReceiverName and PrimaryReceiverPort which 
10 identify the location of the primary receiver server in EAiweb server 146. 

UQOpenConnection can be invoked multiple times to connect multiple receiver 
servers in EAtweb server 146 to UQ system 102, and UQ system 102 maintains a list of 
all connections to the connected receiver servers. After a successful 
UQOpenConnection, the function UQInitRules can be invoked to download agent skill 

15 information, as well as rules for escalating agents and specifying routes. In one 

embodiment, UQInitRules is invoked only once during initialization, and the function 
UQReplaceRules is used to update the rules once they have been initialized. The 
parameter ERROR_UQ_INITIALIZED indicates an error if UQInitRules if subsequently 
invoked. An indicator of whether the initialization was successful is supplied in the 

20 Return parameter associated with the UQInitRules function. 

Agent Logon 

New agents invoke UQOpenConnection through business service 106 to inform 
UQ system 102 that there is a new agent. The function AgentLogon is then invoked by 
UQ business service 106 to log the agent into UQ system 102. UQ business service 106 
25 then sends a message that includes the agent skill information to UQ system 102. 

If multiple receiver servers are connected, each invocation of the function 
AgentLogon includes information about the receiver server that the agent is associated 
with. Agent information also includes information including auto-available setting and 
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auto-wrap setting. UQ system 102 returns either the error if the invocation to 
AgentLogon fails, or returns the new agent state if the logon operation was successful. 

Email Arrival 

When communication server 109 receives an email message, it sends the message 
5 along with related information regarding the client who sent the message to UQ business 
service 106. UQ business service 106 transfers the email message and related 
information to UQ system 102 via the AddWorkltem function. UQ system 102 
determines whether to accept the work item and issues a response to communication 
server 109 via web server 146, EAI serv e r H6, obiect manag er 190. and UQ business 
10 service 106 indicating whether the work item was accepted using the status parameter in 
the HandleWorkltem function. 

UQ Delivers Work Item 

UQ system 102 determines an agent for a work item and sends a message that the 
work item was assigned to an agent to communication server 109 via the receiver server 
15 associated with the agent. UQ system 102 then transmits a message via the 

HandleWorkltem function to the receiver server associated with the agent. The 
ProcessEvents function in UQ business service 106 is then invoked to dispatch the 
message to an agent. The agent invokes the WorkltemAccept function to inform UQ 
system 102 that it received the work item. 

20 UQ System Issues An Alarm Or Error 

As an example of one method for UQ system 102 to notify communication server 
109 of an error or alarm, assume UQ system 102 determines that the number of requests 
that can be handled by one of the communication channels has exceeded a predefined 
threshold. UQ system 102 sends a return code to the receiver server via the HandleError 
25 function indicating that the queue capacity has been exceeded. EA JWeb server 146 

receives the message and invokes the function "ProcessEvents" in UQ business service 
106. The error message can be logged and broadcast to the component that issued the 
request. Alarm messages are handled in a similar manner. The error/alarm can be 
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broadcast visually, aurally, textually, and/or by any other suitable means known in the 
art. 

UQ System Sends Statistics To Communication Server 

A client or other component in system 100 (Fig. 1 A) can request statistics 
5 regarding its communication channels, agents, and/or the routing of agents, from UQ 
system 102 via SetChannelStatlnterval, StartAgentStat, and StopAgentStat functions. 
UQ system 102 generates the requested statistics and transmits them to Web server 146. 
When the receiver server in EAI object manager 190 receives the message, it can log the 
statistics and broadcast them through an interface such as a message bar mechanism, as 
10 known in the art. Agent configurations can be set up to request statistics on a continual 
basis. The statistics can include information for work items completed as well as work 
items in the agent's queue. 

Agent Accepts A Work Item 

When an agent is in AuxWork mode, the agent can choose a work item from the 
15 queue through a user interface such as the toolbar 105. When a work item is selected, 

UQ system 102 is notified via the RequestWorkableltemList function in business service 
106. If the work item is available, the function will indicate a succesful selection 
through the return parameter and the work item is delivered via the HandleWorkltem 
function. The RequestWorkableltemList function can return an error indicator if the 
20 work item is not available for the agent. 

Call Routing 

When UQ system 102 receives a route request, UQ system 102 determines the 
agent to assign to the work item and sends a message to the agent's receiver server in 
EAI object manager 190 that includes the assigned agent and the work item. If UQ 
25 system 102 cannot find an agent to assign within the time allowed, the request is placed 
in a waiting queue as implemented by UQ engine 306. It is important to note that many 
different types of commercially available quein g queuing engines 306 can be used in UQ 
system 102. 
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Automated Call Distribution (ACD) Interaction With The UQ System 

Referring to Figs. 1A-D and 3, an agent can be connected to receive calls directly 
from ACD switch 130E, without interacting with UQ system 102. Agents can also be 
connected to receive calls from ACD switch 130E as well as other work items through 
5 UQ system 102. This type of configuration is referred to auxiliary work mode 

(AuxWork mode). An agent can place themselves in the AuxWork state through an 
interface such as toolbar 105, or an administrator may configure the agent to enter the 
AuxWork state. 

In one implementation of AuxWork mode, ACD switch 130E dispatches a call to 
10 an agent, and the agent informs session mode communication server 110 when it answers 
the call. Session mode communication server 1 10 then relays the notice to UQ system 
102. At this point, UQ system 102 asks session mode communication server 1 10 to 
place the agent in the AuxWork state using, for example, the AgentlnitAuxwork function 
as described herein, after the agent finishes the call. 

15 When the agent finishes the call, it informs session mode communication server 

1 10 that the call is done, and the session mode communication server 1 10 in turn informs 
UQ system 102 that the call is finished. UQ system 102 then determines whether there is 
a suitable work item to assign to the agent based on the media channels in the agent's 
configuration. If a work item is available, the work item will be sent to the agent 

20 through the agent's receiver server in EAI object manager 190. The agent informs UQ 
system 102 when it finishes the work item. If UQ system 102 determines that there are 
no more work items for the agent, it informs session mode communication server 1 10 to 
set the agent's ACD mode to ready to continue receiving calls through ACD switch 
130E. 

25 There are several alternative implementations that can be used to place an agent 

in the AuxWork state. For example, an agent can default to AuxWork state. UQ system 
102 can be notified when ACD switch 130E receives a call that should be handled by the 
agent, and the agent notified to suspend processing a work item, such as a response to an 
email request, to take the call. The agent notifies UQ system 102 when the call is 

30 completed, and returns to processing the suspended work item. 
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Agent State Change 

When a work item is dispatched to an agent, the agent invokes the 
AcceptWorkltem function to accept the work item. Output parameters in 
AcceptWorkltem inform UQ system 102 of the new agent state and work item state. 
When the agent completes the work item, it invokes the CompleteWorkltem function to 
inform UQ system 102 of the new agent state and work item state. 

An auto-wrap option can be set in the agent's configuration table that allows an 
agent time to wrap up a work item upon completion. Agents can select an interface 
option that invokes the AgentAvailable function to indicate that they are out of wrap up 
mode and ready to accept another work item. UQ system 102 changes the status of the 
work item to Complete and places the agent in the Auxwork state if AgentlnitAuxWork 
function has been invoked. If the AgentlnitAuxWork function is not invoked, the 
agent's state is set to BUSY if there are other work items in the queue that the agent can 
handle. Otherwise the agent is placed in the Available state. 

Work Item Cancelled 

A situation can arise when a work item is cancelled after it has been assigned to 
an agent, but before the agent has accepted the work item. Such a situation may arise, 
for example, when a caller hangs up while waiting. In this case, the UQ system 102 
informs the client that the work item is cancelled through HandleWorkltemStatus and a 
signal, such as a blinking button on the agent's user interface display, can be changed to 
indicate that the work item was removed. 

PBX And Email With PBX Higher Priority 

The term private branch exchange (PBX) refers to a subscriber-owned 
telecommunications exchange that usually includes access to the public switched 
network. When an email and a PBX work item are queued, UQ system 102 uses the 
priority set forth in the route rules to determine which media will have higher priority 
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over the other. Client configurations typically give PBX work items higher priority than 
email. 

Work Item Journal 

When a work item is completed, UQ system 102 sends a work item journal entry 
to communication server 109 via the HandleJournal function. The journal entry includes 
information to identify whether the journal entry pertains to the agent state history and/or 
the work item escalation history of the work item. 

System Failure 

If the connection between UQ system 102 and session mode communication 
server 110 fails, UQ system 102 will remove all agents associated with session mode 
communication server 110 and mark all work items as "Complete" with a failure error 
code. 

Multiple Requesters and Receivers 

When UQ business service 106 is instantiated, it will load the UQ configuration 
including the sender's server component name and the workflow name. In one 
embodiment, the sender server component is the EAI object manager 190, which is 
transparent to clients 104. If there are multiple instances of EAI object manager 190, 
communication server 109 routes the request to the appropriate component in 
communication server 109. A load balancer can be included to balance the load between 
multiple instances of EAI object manager 190. 

Each work item sent by UQ clients include a login and a client key associated 
with the work item. When the same work item is being returned form UQ system 102 as 
a result of either an agent assignment or problem with the work item, the login and the 
client key are used to route the result to the right client. 

Blind Transfer Of A Work Item To An Agent 
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An agent can use the function BlindTransferWorkltemToAgent to transfer a work 
item to another agent if the agent cannot respond to the work item, or thinks that another 
agent is better qualified to respond. If the transferree agent is not available to accept the 
work item being transferred, the work item will be queued until the agent is available. 

5 Consultative Transfer Of A Work Item To An Agent 

An agent can invoke the TransferWorkltemToAgent function to transfer a work 
item to another agent to consult with the other agent regarding the work item. If the 
agent is not available for consultation, UQ system 102 informs the agent that the other 
agent is not available. The agent can select whether to hold on to the work item, retry, or 
10 send the work item to a route. 

Transfer Work Item To A Route 

An agent can use the function TransferWorkltemToRoute to transfer a work item 
to along a route to another agent. This is useful, for example, when an agent receives a 
work item that would be handled more efficiently by an agent with other skills. 

15 UQAPI 

In one embodiment, a client server system 100 (Figs. 1 A-E) in accordance with 
the present invention includes UQ API 314 for communicating with UQ system 102. 
For example, the interface can translate information in one format, such as simplified 
object access protocol (SOAP) used by UQ business service 106 to an extensible markup 

20 language (XML) format used in UQ system 102. UQ API 314 can also translate 

information between other formats suitable for use in UQ business service 106 and UQ 
system 102. Alternatively, the same format can be used throughout system 100, thereby 
eliminating the need for UQ API 314. UQ API is further described in copending U.S. 
Patent Application Serial No. . 09/823.678, Attorney Docket No. M-11538 

25 entitled "Extensible Interface For Intermodule Communication", which application was 
filed on the same day is assigned to the same assignee as the present application and is 
incorporated by reference herein. 
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In one embodiment, a user interface for entering and editing agent skills is 
provided. An example of an agent skill graphical user interface (GUI) is described in 
U.S. Patent Application Serial No. , 09/823.531. Attorney Docket No. M-l 1528 

entitled "Communication Toolbar Supporting Multiple Communication Channels of 
5 Different Media Types", which application was filed on the same day and is assigned to 
the same assignee as the present application and is incorporated by reference herein. The 
agent skill GUI includes fields for selecting, entering and editing agent information 
including name, employee number, job title, login name, contact information, skills, and 
the level of expertise for each skill item. After a client updates the skills of an agent 
10 through the agent skill GUI, the ChangeAgentSkill function in UQ business service 106 
can be used to update agent information in UQ system 102. 

UQ API Data Structures 

Figs. 4a-4m show tables representing data structures that are used in one 
15 embodiment of UQ API 314 for communicating information between UQ system 102 
and communication server 109. 

Fig. 4a shows Table UQ_CFG which defines UQ system 102 configuration 
parameters such as the UQ server name, server port, receiver name, and receiver port. 
Fig. 4b defines Table UQ_CFGJPARAM which includes configuration parameters for 
20 UQ system 102 such as the configuration identifier, the name of the configuration. 

Fig. 4c is used for information pertaining to different routes defined for different 
media types, priority, and other characteristics. Fig. 4d further defines the data 
properties of a route. The characteristic of a route can be defined by one or more route 
properties. For example, an email will have "recipient", "subject" and category. A fax 
25 mail will be "DNIS" and "ANI". These characteri s tic characteristics can be translated 

into ski fekills . For example, "Recipient" = "Sales" can be translated into "Department" 
= "Sales". Another example is "DNIS"="8000" can be translated into "Product" = 
"NT". 

Fig. 4e defines how the processing of a work item can be escalated because the 
30 work item has not been served for a pre-defined period of time. Each escalation process 
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defines a way that a work item should be processed. In general, the escalation process is 
to generalize the skill requirement of a work item so that the chance of having the work 
item served is improved. 

Fig. 4f defines the skill requirement for each escalation rule! Each rule 
5 generalizes the skill requirement of a work item. 

Fig. 4g is a map between route property and skill. For example, "DNIS" = 
"8000" could be translated into "Product" = "NT". This is basically a list of possible 
properties for each media. For example, email has subject, CC, recipient. PBX has ANI 
and Language. 

10 Fig. 4h represents the number of end points, also referred to as maximum number 

of sessions, for each media type that an agent is allowed. 

Figs. 4i-4k store route, media, and agent statistics information, respectively. In 
one embodiment, the statistics are sent from UQ system 102 to communication server 
109 at pre-defined time intervals as specified in the UQ configuration passed to UQ 
15 system 102. An agent or administrator can also request statistics when desired through 
communication server 109. Some of the statistics, such as "Average Wait Time" are 
time dependent, and therefore, the time period is also included as part of the data. 

Fig. 41 stores the error log. 

Figs. 4m-4p store the processing history of each work item. 

20 Other tables can be included in an embodiment of UQ system 102 in addition to, 

or instead of, the tables shown in Figs. 4a-4p. 

An Examplary Computing and Network Environment 

Fig. 5 is a block diagram illustrating a network environment in which a 
client/server system 100 according to the present invention may be practiced. As is 
25 illustrated in Fig. 5, network 45, such as a private wide area network (WAN) or the 

Internet, includes a number of networked servers 25(1)-(N) that are accessible by client 
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computers 35(1)-(N). Communication between client computers 35(1)-(N) and servers 
25(1)-(N) typically occurs over a publicly accessible network, such as a public switched 
telephone network (PSTN), a DSL connection, a cable modem connection or large 
bandwidth trunks (e.g., communications channels providing Tl or OC3 service). Client 
5 computers 35(1)-(N) access servers 25(1 )-(N) through, for example, a service provider. 
This might be, for example, an Internet Service Provider (ISP) such as America On- 
Line™, Prodigy™, CompuServe™ or the like. Access is typically had by executing 
application specific software (e.g., network connection software and a browser) on the 
given one of client computers 35(1 )-(N). 

10 It will be noted that the variable identifier "N" is used in several instances in Fig. 

5 to more simply designate the final element (e.g., servers 25(1)-(N) and client 
computers 35(1)-(N)) of a series of related or similar elements (e.g., servers and client 
computers). The repeated use of such variable identifiers is not meant to imply a 
correlation between the sizes of such series of elements, although such correlation may 
15 exist. The use of such variable identifiers does not require that each series of elements 
has the same number of elements as another series delimited by the same variable 
identifier. Rather, in each instance of use, the variable identified by "N" may hold the 
same or a different value than other instances of the same variable identifier. 

One or more of client computers 35(1)-(N) and/or one or more of servers 25(1)- 
(N) may be, for example, a computer system of any appropriate design, in general, 
including a mainframe, a mini-computer or a personal computer system. Such a 
computer system typically includes a system unit having a system processor and 
associated volatile and non-volatile memory, one or more display monitors and 
keyboards, one or more diskette drives, one or more fixed disk storage devices and one 
or more printers. These computer systems are typically information handling systems 
which are designed to provide computing power to one or more users, either locally or 
remotely. Such a computer system may also include one or a plurality of I/O devices 
(i.e., peripheral devices) which are coupled to the system processor and which perform 
specialized functions. Examples of I/O devices include modems, sound and video 
devices and specialized communication devices. Mass storage devices such as hard 
disks, CD-ROM drives and magneto-optical drives may also be provided, either as an 
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integrated or peripheral device. One such example computer system, discussed in terms 
of client computers 35(1)-(N) is shown in detail in Fig. 6. 

Fig. 6 depicts a block diagram of a computer system 10 suitable for implementing 
the present invention, and example of one or more of client computers 35(1)-(N). 
5 Computer system 10 includes a bus 12 which interconnects major subsystems of 
computer system 10 such as a central processor 14, a system memory 16 (typically 
RAM, but which may also include ROM, flash RAM, or the like), an input/output 
controller 18, an external audio device such as a speaker system 20 via an audio output 
interface 22, an external device such as a display screen 24 via display adapter 26, serial 
10 ports 28 and 30, a keyboard 32 (interfaced with a keyboard controller 33), a storage 

interface 34, a floppy disk drive 36 operative to receive a floppy disk 38, and a CD-ROM 
drive 40 operative to receive a CD-ROM 42. Also included are a mouse 46 (or other 
point-and-click device, coupled to bus 12 via serial port 28), a modem 47 (coupled to bus 
12 via serial port 30) and a network interface 48 (coupled directly to bus 12). 

15 Bus 12 allows data communication between central processor 14 and system 

memory 16, which may include both read only memory (ROM) or flash memory (neither 
shown), and random access memory (RAM) (not shown), as previously noted. The 
RAM is generally the main memory into which the operating system and application 
programs are loaded and typically affords at least 16 megabytes of memory space. The 

20 ROM or flash memory may contain, among other code, the Basic Input-Output system 
(BIOS) which controls basic hardware operation such as the interaction with peripheral 
components. Applications resident with computer system 10 are generally stored on and 
accessed via a computer readable medium, such as a hard disk drive (e.g., fixed disk 44), 
an optical drive (e.g., CD-ROM drive 40), floppy disk unit 36 or other storage medium. 

25 Additionally, applications may be in the form of electronic signals modulated in 

accordance with the application and data communication technology when accessed via 
network modem 47 or interface 48. * 

Storage interface 34, as with the other storage interfaces of computer system 10, 
may connect to a standard computer readable medium for storage and/or retrieval of 
30 information, such as a fixed disk drive 44. Fixed disk drive 44 may be a part of 

computer system 10 or may be separate and accessed through other interface systems. 
Many other devices can be connected such as a mouse 46 connected to bus 12 via serial 
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port 28, a modem 47 connected to bus 12 via serial port 30 and a network interface 48 
connected directly to bus 12. Modem 47 may provide a direct connection to a remote 
server via a telephone link or to the Internet via an internet service provider (ISP). 
Network interface 48 may provide a direct connection to a remote server via a direct 
5 network link to the Internet via a POP (point of presence). Network interface 48 may 
provide such connection using wireless techniques, including digital cellular telephone 
connection, Cellular Digital Packet Data (CDPD) connection, digital satellite data 
connection or the like. 

Many other devices or subsystems (not shown) may be connected in a similar 
10 manner (e.g., bar code readers, document scanners, digital cameras and so on). 

Conversely, it is not necessary for all of the devices shown in Fig. 6 to be present to 
practice the present invention. The devices and subsystems may be interconnected in 
different ways from that shown in Fig. 6. The operation of a computer system such as 
that shown in Fig. 6 is readily known in the art and is not discussed in detail in this 
15 application. Code to implement the present invention may be stored in computer- 
readable storage media such as one or more of system memory 16, fixed disk 44, CD- 
ROM 42, or floppy disk 38. Additionally, computer system 10 may be any kind of 
computing device, and so includes personal data assistants (PDAs), network appliance, 
X-window terminal or other such computing device. The operating system provided on 
20 computer system 10 may be MS-DOS®, MS-WINDOWS®, OS/2®, UNIX®, Linux® 
or other known operating system. Computer system 10 also supports a number of 
Internet access tools, including, for example, an HTTP-compliant web browser having a 
JavaScript interpreter, such as Netscape Navigator® 3.0, Microsoft Explorer® 3.0 and 
the like. 

25 Moreover, regarding the signals described herein, those skilled in the art will 

recognize that a signal may be directly transmitted from a first block to a second block, 
or a signal may be modified (e.g., amplified, attenuated, delayed, latched, buffered, 
inverted, filtered or otherwise modified) between the blocks. Although the signals of the 
above described embodiment are characterized as transmitted from one block to the next, 

30 other embodiments of the present invention may include modified signals in place of 

such directly transmitted signals as long as the informational and/or functional aspect of 
the signal is transmitted between blocks. To some extent, a signal input at a second 
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block may be conceptualized as a second signal derived from a first signal output from a 
first block due to physical limitations of the circuitry involved (e.g., there will inevitably 
be some attenuation and delay). Therefore, as used herein, a second signal derived from 
a first signal includes the first signal or any modifications to the first signal, whether due 
5 to circuit limitations or due to passage through other circuit elements which do not 
change the informational and/or final functional aspect of the first signal. 

The foregoing described embodiment wherein the different components are 
contained within different other components (e.g., the various elements shown as 
components of computer system 10). It is to be understood that such depicted 

10 architectures are merely examples, and that in fact many other architectures can be 
implemented which achieve the same functionality. In an abstract, but still definite 
sense, any arrangement of components to achieve the same functionality is effectively 
"associated" such that the desired functionality is achieved. Hence, any two components 
herein combined to achieve a particular functionality can be seen as "associated with" 

15 each other such that the desired functionality is achieved, irrespective of architectures or 
intermediate components. Likewise, any two components so associated can also be 
viewed as being "operably connected", or "operably coupled", to each other to achieve 
the desired functionality. 

Fig. 7 is a block diagram depicting a network 50 in which computer system 10 is 
20 coupled to an internet 60, which is coupled, in turn, to client systems 70 and 80, as well 
as a server 90. Internet 60 (e.g., the Internet) is also capable of coupling client systems 
70 and 80 and server 90 to one another. With reference to computer system 10, modem 
47, network interface 48 or some other method can be used to provide connectivity from 
computer system 10 to internet 60. Computer system 10, client system 70 and client 
25 system 80 are able to access information on server 90 using, for example, a web browser 
(not shown). Such a web browser allows computer system 10, as well as client systems 
70 and 80, to access data on server 90 representing the pages of a website hosted on 
server 90. Protocols for exchanging data via the Internet are well known to those skilled 
in the art. Although Fig. 7 depicts the use of the Internet for exchanging data, the present 
30 invention is not limited to the Internet or any particular network-based environment. 

Referring to Figs. 1, 2 and 3, a browser running on computer system 10 employs 
a TCP/IP connection to pass a request to server 40, which can run an HTTP "service" 
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(e.g., under the WINDOWS® operating system) or a "daemon" (e.g., under the UNIX® 
operating system), for example. Such a request can be processed , for example, by 
contacting an HTTP server employing a protocol that can be used to communicate 
between the HTTP server and the client computer. The HTTP server then responds to 
5 the protocol, typically by sending a "web page" formatted as an HTML file. The 

browser interprets the HTML file and may form a visual representation of the same using 
local resources (e.g., fonts and colors). 

The foregoing detailed description has set forth various embodiments of the 
present invention via the use of block diagrams, flowcharts, and examples. It will be 
10 understood by those within the art that each block diagram component, flowchart step, 
and operations and/or components illustrated by the use of examples can be 
implemented, individually and/or collectively, by a wide range of hardware, software, 
firmware, or any combination thereof. 

The present invention has been described in the context of a fully functional 
15 computer system, however those skilled in the art will appreciate that the present 

invention is capable of being distributed as a program product in a variety of forms, and 
that the present invention applies equally regardless of the particular type of signal 
bearing media used to actually carry out the distribution. Examples of signal bearing 
media include: recordable type media such as floppy disks and CD-ROM, transmission 
20 type media such as digital and analog communications links, as well as media storage 
and distribution systems developed in the future. 

The above description is intended to be illustrative of the invention and should not 
be taken to be limiting. Other embodiments within the scope of the present invention are 
possible. Those skilled in the art will readily implement the steps necessary to provide the 

25 structures and the methods disclosed herein, and will understand that the process 

parameters and sequence of steps are given by way of example only and can be varied to 
achieve the desired structure as well as modifications that are within the scope of the 
invention. Variations and modifications of the embodiments disclosed herein can be 
made based on the description set forth herein, without departing from the spirit and scope 

30 of the invention as set forth in the following claims. 
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